Entity vs Value Object

Question

Я пытаюсь изучить и применить DDD к новому проекту, поэтому столкнувшись с вопросом, который может быть чем-то очень простым, но я, возможно, пропустил.

Может ли ограниченный контекст содержать объект, а также объект значения для одного и того же объекта?

Мой вопрос возникает из-за того, что нам обычно нужен ViewModel, который обязан хранить детали, которые ближе к представлению, в дополнение к данным модели. Но бывают случаи, когда ограниченный контекст может использовать какой-либо объект в качестве ссылочного объекта в транзакции.

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

Отдел может быть создан/обновлен и т. Д. В этом домене. Затем мы можем добавить сотрудников в эти отделы.

Теперь, когда мы показываем сотрудника, мы хотели бы отобразить некоторую информацию о отделе, который может не понадобиться всему подразделению отдела. Нам может понадобиться около 50% деталей в отделе.

Мой вопрос в том, может ли у нас есть другой ValueObject для отдела в таких сценариях? Или это что-то сломает?

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

сделать ли мое мышление смысл?

Answer 1

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

Отдел организация

• живет в доменной модели
• может использоваться в различных случаях использования на этой модели

Резюме отдел объекта

• Существует только для поддержки конкретного вида
• не является объектом значения в смысле DDD
• не живет в доменной модели

Итак, где вы должны поставить отдел сводного класс? Сводный класс представляет собой проблему с сервисом приложений/пользовательского интерфейса, но механизм персистентности, вероятно, нуждается в нем, чтобы структурировать данные в интерфейсе репозитория (если вы хотите избежать переупаковки объектов).

Попробуйте установить его рядом с сервисом приложения, потому что это то, где он логически принадлежит. В зависимости от вашей архитектуры вам понадобится сопоставление «объект-объект», чтобы получить данные из репозитория в итоговые объекты.