DDD - Является ли модель анемичного домена антипаттерном? Должны ли мы использовать богатые доменные модели? [закрыто]

Модель анемичной предметной области была подвергнута давней критике Эвансом и Фаулером , поскольку она явно идет вразрез с объектно-ориентированными принципами и т. Д. Сообщество DDD четко согласуется с этими утверждениями.

Однако в последние годы раздавались голоса, утверждающие, что это вовсе не антипаттерн и что это пример следования принципам SOLID.

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

Мои вопросы: анемичная модель предметной области все еще считается антипаттерном? Мы все делали вещи (относительно DDD) неправильно? Не думаете ли вы, что наличие моделей Rich Domain нарушает принципы SOLID?

ADM - хороший шаблон для решения распределенных сервисов, таких как микросервисы. Он подходит для многих современных бизнес-кейсов.

Рассмотрим, есть ли у нас объект Order Domain. При подходе ООП мы бы добавили Order.Purchase () Order.Cancel () и т. Д. Это будет хорошо работать в настольном приложении, где мы храним заказы в памяти и выполняем несколько операций с одним экземпляром.

Но если у нас есть распределенная система с программами, которые предназначены только для одной цели, то есть для доступа к списку заказов и покупки каждого по очереди, или для получения списка заказов и отмены каждого по очереди, то использование обоих методов для одного и того же объекта не дает смысл. У нас должно быть два домена или ограниченный контекст:

PurchaseSystemOrder.Purchase()

а также

CancelSystemOrder.Cancel();

Единственное, что эти объекты разделяют, это структура данных свойств.

По мере того, как вы добавляете все больше и больше микросервисов, вы получаете десятки типов ордеров. Он больше не имеет смысла говорить о качестве ордена в качестве объекта домена, несмотря на то, его же концептуальном порядке , который обрабатывается всеми этими системами.

Гораздо разумнее иметь модель Anemic Order, которая просто инкапсулирует только данные и соответственно переименовывает ваши сервисы:

PurchaseService.Purchase(Order order)

Теперь мы можем снова поговорить о заказе и добавить любые новые сервисы, которые мы придумаем для обработки, не затрагивая другие развернутые в настоящее время сервисы.

Фаулер и Ко происходят из монолитной системы, в их мире подход ADM означал бы одно приложение, в котором все эти отдельные службы были бы созданы в памяти, а OrderDTO передавался и мутировал. Это было бы намного хуже, чем помещать методы в модель богатого порядка.

Но в распределенной системе существует много программ, каждая из которых требует только одного метода Order и запускает его по нескольким заказам, загружая каждую, запуская метод, а затем отбрасывая его. Для этого требуется только один Сервис и поток объектов данных.

Полное заполнение богатой модели, беспокоясь о требованиях и зависимостях всех методов только для вызова одного и последующего немедленного отказа от объекта, бессмысленно.

Кроме того, изменение одного из методов потребовало бы обновления всех распределенных компонентов, поскольку все они зависят от модели Rich для своей логики.

У меня нет места в моей базе кода для вещей, которые им не нужны

SOLID и DDD ортогональны друг другу, что означает, что они действительно идут в разных направлениях друг от друга. Не следует говорить, что один используется для исключения другого, поскольку они могут и, вероятно, должны существовать вместе в одной кодовой базе.

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

DDD - превосходная парадигма для микро-услуг из-за концепции ограниченного контекста .

Остерегайтесь соблазна увидеть инфраструктурный код как часть вашего домена. Инфраструктурный код - это все, что вы не написали сами, или что-либо, связанное с платформой или библиотекой, которая взаимодействует со сторонней системой. Соединения с базой данных, почтовые программы SMTP, библиотеки ORM, время выполнения сервера приложений, все это - инфраструктура, и вы не должны включать или зависеть от этого в своем домене, если можете избежать этого.

Принципы SOLID - это набор концепций ООП общего назначения, которые вы можете использовать для улучшения кода ООП. Вы можете написать хорошую базу кода DDD, используя их.

Богатый домен хорош, когда все сделано хорошо. Кошмар, когда нет. Анемичный домен - это всегда плохо. Но это знакомый удобный вид плохо.

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

Многие фреймворки пробираются в языковое пространство, пока вы не можете больше рекламировать работу как работу Java. Это работа на Java / Spring. Помимо того, что они заставляют вас зависеть от них, они превращают язык общего назначения в ублюдочную форму языка 4-го поколения.

Это лучшая практика или анти-паттерн? Ну, вы, босс, в основном заботитесь о том, можете ли вы нанять людей для работы над кодовой базой. Поэтому, если нам придется притворяться, что мы используем язык общего назначения, чтобы нанимать людей, мы будем.

Если ты в порядке с этим, тогда хорошо. Вы, конечно, не единственный.

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

У меня нет места в моей базе кода для вещей, которые ему не нужны.

Что касается SOLID и других принципов проектирования, я могу в значительной степени следовать им даже в анемичной области. Несоблюдение этих требований вызывает другие проблемы.