Агрегаты DDD по сравнению с сущностями

#domain-driven-design #aggregateroot

Вопрос:

Что делать с объектом, имеющим две зависимости:

Допустим, у нас есть три объекта: клиент, компания и контракт. Контракт нуждается в клиенте и компании, чтобы существовать.

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

На данный момент у меня есть все три как отдельный совокупный корень. Потому что вы также должны иметь возможность быстро запрашивать существующие контракты для конкретной компании. Если бы контракт был сущностью в корне совокупности клиентов, мне нужно было бы запросить всех клиентов, у которых есть контракт компании X, а затем вернуть сжатый список этих контрактов. Что показалось немного странным?

Во-вторых, в самом контракте много сущностей, а ниже их еще больше сущностей.

Чтобы объяснить иерархию простым способом:

Агрегаты контрактов содержат список сущности A, сущность A содержит несколько элементов сущности B, а сущность B содержит несколько элементов сущности C. Таким образом, это глубокая структура, которая должна быть раскрыта через совокупность над ней.

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

Итак, мой вопрос таков: какие вопросы я могу задать себе, чтобы ответить на такого рода вопросы? Вероятно, нет правильного или неправильного, но должны быть какие-то рекомендации о том, как справиться с подобной проблемой?

Спасибо!

Ответ №1:

какие вопросы я могу задать себе, чтобы ответить на такого рода вопросы?

Вот как Эрик Эванс определил СОВОКУПНОСТЬ

Агрегат-это кластер связанных объектов, которые мы рассматриваем как единое целое с целью изменения данных.

«Изменение»-это важная идея здесь; при разработке наших совокупных границ мы не особенно заботимся о данных, которые отображаются в одном и том же отчете (представление только для чтения), вместо этого мы заботимся о том, какие данные необходимо учитывать при внесении изменений.

См.Также Мауро Сервьенти: Все наши агрегаты неверны.