DDD: ограниченные контексты - доменные объекты, которые ссылаются на проблемы в другом ограниченном контексте

Question

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

Например: У клиента есть много продуктов в контексте клиента Компания имеет и список продуктов в контексте компании

Таким образом, клиент управляется через контекст клиента, а компания - через контекст компании

Учитывая контексты в разных модулях.

Если я хочу предоставить информацию об адресе компании вместе с продуктом, как это следует делать?

Должен ли я ссылаться на модуль, содержащий контекст Company, в модуле, содержащем клиента, или я создаю сущность Company в контексте клиента специально для использования при взаимодействии с клиентами?

Спасибо

Answer 1

Вы можете иметь разные представления одной и той же сущности в разных ограниченных контекстах. Компания в Company BC может сильно отличаться от компании в User BC. Все, что им нужно поделиться, это какой-то корреляционный идентификатор.

Answer 2

Вот как мы подошли к этому и в нашем проекте.

Для одного ограниченного контекста мы использовали контракт в качестве Агрегированного корня, в то время как в другом ограниченном контексте мы использовали контракт в качестве объекта значения / сущности

В первом модуле / BC у нас был большой класс контракта с большим поведением, в то время как во втором модуле / BC у нас был другой класс контракта, который содержал только несколько свойств с частными установщиками.

Таким образом, было бы возможно разделить 2 BC на отдельные сборки сервисов даже в дизайне SOA.