Модель анемичной доменной модели против доменной модели в простом доменном дизайне

Question

Недавно я прочитал пост " Модель анемичной доменной модели ", который привлек мое внимание. Прочитав это, я обнаружил, что описание Anemic Domain Model применимо ко многим проектам, над которыми я работал и создавал. Я никогда не думал об этом как о плохом дизайнерском решении, поскольку это чувствовало себя очень естественным. Я подумал, что в случае, когда модель домена была легкой и не очень сложной, моникер Anemic Domain Model вполне подходил. Зачем добавлять сложность в модель предметной области, если она не обязательна, так что название «Анемичная модель предметной области» не точно описывает ваш код?

Вопрос: В какой момент встраивание большего количества ваших сложностей кода в ваш сервис / прикладной уровень становится неправильным в пользу того, чтобы вместо этого выявлять сложность объектов вашей сущности? Я за то, чтобы иметь свойство «Итого» на сущности, где оно может самостоятельно определить значение для итога. Я не за то, чтобы сущность общалась напрямую с различными другими виджетами, чтобы определить результат одного из его свойств. Так является ли концепция модели анемичной области анти-паттерном или хорошим разделением интересов? Название Anemic Domain Model всегда плохо?

Просто любопытно, что думают другие люди об этом шаблоне (анти).

Answer 1

Ключевой вопрос: , почему модель домена анемична?

• Практически полное отсутствие бизнес-логики, как в приложении, которое в основном представляет собой совокупность экранов CRUD ?
• Сервис-ориентированная архитектура, в которой «доменные объекты» фактически являются простыми структурами объектами передачи данных ?
• Политические или прагматические соображения, такие как владение кодом или прямая / обратная совместимость, которые чрезмерно затрудняют рефакторинг?
• Применение процедурного / реляционного проектирования на объектно-ориентированном языке?

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

Answer 2

Если домен легкий (читай: не сложный), рекомендуется использовать простые объекты типа ActiveRecord на уровне основного домена. Обычно взаимно-однозначное сопоставление между таблицами БД и объектами вашего домена, и здесь не так уж много «логики». Ваше приложение просто перетасовывает записи между базой данных и вашим пользовательским интерфейсом и позволяет выполнять простые операции CRUD.

Для сложных доменов вы должны построить модель основного домена, в которой некоторые объекты будут отображаться в таблицы БД, а некоторые, скорее всего, не будут представлять и представлять другие концепции в вашем домене, кроме простых данных. Логика для приложения должна быть внутри объектов, когда это уместно, или внутри объектов Service, если это требует координации между несколькими объектами домена.

Анти-паттерн Anemic Domain Model применяется, когда у вас сложный домен, но вместо того, чтобы надлежащим образом помещать некоторую логику в объекты домена и некоторую логику в службы, вы помещаете ВСЕ (или почти всю) логику, внешнюю по отношению к вашему базовому домену. объекты.

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

Answer 3

G'day!

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

AOP делает это до определенной степени, но, в конце концов, одна из ключевых концепций ориентации объекта исчезла.

С уважением, Stefan