Как вы обрабатываете ассоциации между агрегатами в DDD?

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

По деловым причинам Отгрузки - это их собственные агрегаты, и все же они должны быть явно привязаны к Клиентам. Должна ли компания-заказчик домена иметь список отправлений? Если да, то как мне заполнить этот список на уровне репозитория - учитывая, что у меня будет CustomerRepository и ShipmentRepository (по одному репо за совокупность)?

Я говорю "ассоциация", а не "отношения", потому что хочу подчеркнуть, что это решение домена, а не инфраструктурное. Я сначала проектирую систему из модели.

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

Ответ 1

Нет причин, по которым ваш ShipmentRepository не может агрегировать данные клиента в ваши модели отправки. Репозитории не должны иметь сопоставление 1-к-1 с таблицами.

У меня есть несколько репозиториев, которые объединяют несколько таблиц в одну модель домена.

Ответ 2

Я думаю, что есть два уровня ответа на этот вопрос. На одном уровне возникает вопрос, как я могу установить связь между клиентом и отгрузкой. Мне очень нравится семантика заливки, в которой у вашего репозитория отгрузки может быть fillOrders (список клиентов,....).

Другим уровнем является "как мне обрабатывать денормализованные модели домена, которые являются частью DDD". И "Клиент", вероятно, лучший пример из всех, потому что он просто проявляется в таких разных контекстах; почти у всех ваших процессов есть клиент в них, и контекст клиента обычно чрезвычайно разнообразен. В макс половину времени вас интересуют "заказы". Если бы мое понимание домена было прекрасным, когда я начинал, я бы никогда не стал концепцией клиентского домена. Но это не так, поэтому я всегда делаю объект Customer. Я до сих пор помню проект, где я через 3 года почувствовал, что смогу создать надлежащую модель домена "Клиент". Я буду искать альтернативные и более подробные концепции, которые также представляют клиента; PotentialCustomer, OrderingCustomer, CustomerWithOrders и, возможно, несколько других; извините, имена не лучше. Мне нужно еще немного времени для этого;)

Ответ 3

Отгрузка имеет отношение "все-к-одному" с Клиентом. Если вы ищете поставки клиента, добавьте запрос в репозиторий доставки, который принимает клиентский параметр.

В общем, я не создаю связи один-к-mane между объектами, когда многие стороны не ограничены.