модель анемичного домена в сравнении с моделью домена - PullRequest
Новая
       47

модель анемичного домена в сравнении с моделью домена

19 голосов
/ 27 ноября 2009

Снова запутавшись после прочтения об этом анти-паттерне и множестве опасений по этому поводу здесь, на SO.

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

У меня сложилось впечатление, что захват того, что должно сохраняться в доменной модели, нарушает передовую практику и создает анти-паттерн анемичной доменной модели. Тем не менее, если вы используете реляционную БД, невозможно избежать выделения части, которая создает состояние объекта, и сохранить его.

Поскольку я довольно запутался в понятиях, я не уверен, что то, что я пишу, имеет смысл. Не стесняйтесь спрашивать разъяснения.

Ответы [ 3 ]

17 голосов
/ 27 ноября 2009

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

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

К вопросу о DTO: не игнорируйте их. С точки зрения реализации они вам понадобятся для передачи данных между слоями / уровнями. То, как вы комбинируете DTO и настоящие доменные объекты, зависит от используемой вами технологии.

Как уже упоминалось в предыдущем ответе, возможно, ваше внимание на data и персистентность отвлекает вас от true моделирования области ...

10 голосов
/ 27 ноября 2009

Мне на ум приходят две вещи:

  • Объекты передачи данных (DTO) отличаются от объектов домена. Они служат разным целям в разных местах архитектуры - не путайте их. Доменные объекты предоставляют богатый API с высокой связностью . DTO - это пассивные структуры данных , используемые во внешнем интерфейсе приложения - совсем как UM ViewModels, но нацеленные на автоматизированные системы вместо пользователей.
  • Стремитесь после выбора ORM, который позволяет вам использовать Постоянство Невежество . Это означает, что вы можете неограниченно определять вашу модель предметной области и просто использовать ORM для сопоставления объектов с реляционной базой данных.
3 голосов
/ 27 ноября 2009

Но если я добавлю достаточное количество логики домена в эту оболочку, в какой момент она станет настоящей моделью домена?

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

...