DDD, как обрабатывать агрегатные корни, которые обмениваются данными

Question

В настоящее время я работаю над приложением Аренда недвижимости (PHP) и пытаюсь разобраться с DDD ...

При обнаружении ограниченного контекста «Период аренды» (BC) и «Биллинг» BC я заметил, что оба BC имеют совокупный корень «Арендатор» (AG). Но значение «Арендатора», кажется, различается в каждом BC.

В BC «Период аренды» действует бизнес-правило, согласно которому все арендаторы должны быть не моложе 18 лет. Таким образом, Tenant AG должен иметь «TenantId», «TenantName» и «DateOfBirth».

В контексте выставления счетов важны такие вещи, как TenantID, TenantName и BillingAddress, но не возраст арендаторов.

Ни один из этих двух BC не имеет 100% всех данных арендатора.

Итак, мой вопрос, означает ли это, что должен существовать отдельный BC (TenantManagement), которому принадлежит 100% данных арендаторов, и что арендаторы в двух других BC будут иметь только подмножество этих данных, которое следует рассматривать как только для чтения?

Answer 1

Определенно: нет.Там не должно быть «TenanatManagement» BC.Арендатор - это другое понятие в Периоде аренды и до выставления счетов.В DDD вы не моделируете данные, и нет необходимости в центральной модели данных.Одна из целей разделения домена на поддомены состоит в том, чтобы избежать наличия несвязанных и, возможно, противоречащих друг другу концепций в одной модели.

Answer 2

Совсем нет, в DDD вполне нормально иметь дублирование данных.

Централизация данных - это традиционная концепция, которая годами является причиной высокого уровня связи среди недоброкачественных программных продуктов.

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

Что вам нужно знать, так это то, как они обновляются прослушивателем сообщений?Кто является владельцем данных?Биллинг сервис?управление арендой?и то и другое ?внешняя система?Это вопросы, которые вам нужно задать себе, и затем вы просто внедряете слушателей на своих двух BC.