Какие проблемы вы обнаружите в этом представлении для проекта, управляемого доменом?

Я только что написал длинный (и беспорядочный) blogpost о моем представлении о доменном дизайне в настоящее время с такими фреймворками, как spring и спящий режим в массовом порядке.

Я бы попросил вас выявить какие-либо проблемы с моими взглядами по этому вопросу - почему это не сработает, почему это не дает преимуществ DDD, почему это вообще не очень хорошая идея.

Блогпост здесь (я не думаю, что мне нужно скопировать-вставить его на SO - если вы думаете, что я должен, скажите мне).

Я знаю, что вопрос субъективен, но он направлен на сбор наиболее распространенных мнений.

(Я отмечаю Java, так как обсуждаемые рамки - это Java-фреймворки)

Ответ 1

Я только что провел год своей жизни, разрывая приложение, чтобы устранить анти-шаблон анемичного домена и его неправильное использование Hibernate.

Я могу без всякого сомнения сказать, что код, который появляется в результате DDD, намного проще понять и реорганизовать. В нашем случае удаление бесчисленных ненужных геттеров и сеттеров, увеличение инкапсуляции, концентрация бизнес-логики и, как следствие, (резкое) упрощение слоев услуг, которые приходят вместе с DDD, сделали систему намного проще в обслуживании что теперь я верю, что мы сможем закончить его, пока он не затянулся навсегда. Мы сократили количество строк этого приложения на 50%, не удаляя никаких функций.

Я также считаю, что вся точка инструмента ORM заключается в том, что моя бизнес-логика не содержит изменений в коде персистентности. Когда у нас была модель анемичного домена, у нас был DAO для каждого класса домена, теперь у нас есть небольшая часть DAO как точка входа для CRUD на "основные" классы домена, но другие "второстепенные" классы домена обрабатываются их родители... не потому, что логика настойчивости находится в родительском, а потому, что Hibernate прозрачно реагирует на бизнес-логику и делает все, что просто работает.

Короче говоря, я не могу ответить на этот вопрос, потому что я категорически согласен с вашим сообщением на 100%... и живу каждый день.

Ответ 2

Мы идем с подходом "анемичной модели", чтобы мы могли повторно использовать одни и те же модели с другой бизнес-логикой. Однако мы используем вычисления и вспомогательные методы в наших моделях, если они применимы для всех случаев. Но мы ничего не вводим в наши модели и не вводим наши модели в IoC.

Ответ 3

Лично я не убежден, что часть об инъекции объектов репозитория в объекты домена (что означает постоянные сущности) необходима с помощью Spring и Hibernate. Hibernate уже предоставляет постоянные коллекции, которые могут выполнять ленивую загрузку, поэтому у вас уже есть возможность пересекать модель домена таким образом, чтобы отделить инфраструктуру доступа к данным от бизнес-логики. Я не вижу, какое значение добавляет репозитории на модель домена.

РЕДАКТИРОВАТЬ: Ой, разместил это перед чтением всей статьи. Теперь, когда я прочитал весь пост в блоге, я думаю, что согласен с этим. Мне нравится часть, рекомендующая делать без DTO, где это возможно.