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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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