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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

  

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

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