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

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

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

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

Ответы

Ответ 1

Ключевой вопрос - спросить почему анемия для модели домена?

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

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

Ответ 2

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

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

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

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

Ответ 3

G'day!

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

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

С уважением, Стефан