Определение границ и взаимодействие между совокупными корнями

Question

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

У меня есть сводный корень, который называется Department.У объекта Department есть несколько дочерних типов значений, которые помогают определить бизнес-понятие «отдела».В моем пользовательском интерфейсе пользователи могут перечислять, создавать, редактировать и удалять объекты Department.

У меня есть еще один сводный корень Project.Проект имеет несколько дочерних типов значений, но также имеет отношение к Департаменту, поскольку каждый проект «принадлежит» департаменту.Проекты можно создавать, редактировать, удалять и т. Д., И это не влияет на отдел, тогда как удаление отдела также удаляет все принадлежащие ему проекты.

Мой пользовательский интерфейс отобразит список проектов на основе отделовтекущий пользователь авторизован для доступа.Они могут иметь доступ к нескольким отделам.При отображении как элемента списка, так и в деталях, мне нужно показать логотип Отдела вместе с Проектом.

Сначала я подумал, что Проект - это объединенный корень с простым свойством DepartmentID, которое можно использовать для«искать» отдел.Но теперь я начинаю думать, что у меня действительно только один сводный корень: Department.

Что вы думаете?

UPDATE

Iне знаю, является ли это ключом к обсуждению или что-то меняет, но после прочтения первой пары ответов мне пришла в голову следующая мысль:

У отдела, по-видимому, два контекста:

1. Как автономный объект, который поддерживает модификацию.
2. Как дочерний элемент проекта, в котором случай содержит данные только для чтения и никакого поведения.

Это заставляет меня думать, чтоУ меня должно быть два «объекта» в моей модели, совокупный корень для случая # 1 и тип значения для случая # 2.Я на правильном пути?

Answer 1

Я думаю, что совершенно оправданно иметь как Project, так и Department как совокупные корни, так как они оба управляются независимо.

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

Вам просто нужно сохранить ссылку на отдел в каждом проекте.

Answer 2

Поскольку Проект не может существовать без Департамента, это, вероятно, не Совокупный корень.Из вашего описания звучит так, будто у вас есть только один AR - Департамент, который вы используете для управления проектами внутри него.

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

ОБНОВЛЕНИЕ Как вы упоминаете, у вас может быть 2 ограниченных контекста здесь.Тот, где Департамент является АР, а Проекты являются субъектами этого АР.В этом контексте вы будете выполнять операции с вашими отделами.Через секунду до н.э. ваш проект может быть AR, а департаменты могут быть субъектами или VO.Это позволит вам работать напрямую с проектами.

Я бы также порекомендовал обсудить это с вашим экспертом по доменам и посмотреть, хорошо ли подходят эти концепции в вашем UL, или, возможно, найти какой-то недостающий концепт, который может прояснить вашу модель.Я бы особенно искал концепцию, которая могла бы связать проекты с отделами.

Answer 3

Несколько простых вопросов для ответа:

1) может ли объект домена отдела жить самостоятельно без объекта домена Проекта.- Если да, то отдел является агрегатом.

2) Может ли объект домена Project жить самостоятельно - Если да, то проект также является агрегатом

3) Является проектомимеет отношения с одним отделом - тогда он должен быть частью совокупности проекта, представленной как свойство Department

4) если отдел имеет отношения с одним или несколькими объектами проекта - агрегат проекта должен быть частью агрегата отделаobject.

Итак, используя агрегатный объект Department, вам может потребоваться доступ к списку объектов Project (s), а после получения объекта Project вам может понадобиться доступ к объекту Department.Это круговая ссылка, которая устарела.

Это типичный пример того, как Сотрудник имеет менеджера, а менеджер имеет список сотрудников