анемическая модель домена по сравнению с моделью предметной области

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

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

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

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


design-patterns domain-driven-design anti-patterns anemic-domain-model
person koen    schedule 26.11.2009    source источник
comment
Возможный дубликат модели анемичного домена vs. Модель предметной области в простом дизайне, ориентированном на предметную область   -  person jaco0646    schedule 12.10.2018

Ответы (3)


arrow_upward
17
arrow_downward

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

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

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

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

person Vijay Patel    schedule 27.11.2009

arrow_upward
10
arrow_downward

На ум приходят два интересных момента:

  • Объекты передачи данных (DTO) отличаются от объектов домена. Они служат разным целям в разных частях архитектуры - не путайте их. Объекты домена предоставляют богатый API с высокой связностью. DTO - это пассивные структуры данных, используемые во внешнем интерфейсе приложения - они очень похожи на модели представления пользовательского интерфейса, но нацелены на автоматизированные системы, а не на пользователей.
  • Постарайтесь выбрать ORM, который позволяет вам использовать Невежество настойчивости. Это означает, что вы можете определять свою модель предметной области неограниченным образом и просто заставить ORM сопоставлять объекты с реляционной базой данных.
person Mark Seemann    schedule 27.11.2009

arrow_upward
3
arrow_downward

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

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

person pmf    schedule 27.11.2009