Отношение "многие ко многим" в DDD

Я новичок в DDD, и я придерживаюсь отношений "многие ко многим". Например. у нас есть два основных корня - Задачи и Рабочие.

Контракт определенно не является совокупным корнем, поскольку он не имеет смысла без задачи и рабочего. Таким образом, он должен быть частью некоторого агрегата. Но какой совокупностью он должен принадлежать? Нам необходимо знать как итоговые затраты по всем контрактам, так и суммарные затраты всех контрактов на работу. И для меня естественно иметь сбор контрактов как в Task, так и в Worker.

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

Спасибо!

Ответ 1

Следуя связанным вопросам, связанным на боковой панели, я нашел эту интересную статью:

DDD и много-много реляционных карт объектов

Кажется, я рекомендую то, что я интуитивно думал, так или иначе, что на самом деле для рабочего и на самом деле естественным является зависимость от контракта. То есть понятие "рабочий" по-прежнему имеет смысл без понятия "контракт" (и аналогично для задачи), поэтому субъект, воплощающий эту концепцию, не должен иметь зависимость от контрактной сущности.

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

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

Итак, мое предложение, с проницательностью из комментариев от комментариев:

Ответ 2

Contract представляется мне первоклассным объектом в вашем дизайне. Ваше утверждение о том, что оно не имеет смысла вне контекста как worker, так и task, конечно, верно, но это не значит, что он не является совокупным корнем в своем собственном праве.

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

Разрыв, который необходимо переместить, перемещает контекст релевантного в объект Contract. Пусть он сохраняет скорость worker и период task (в дополнение к соответствующим идентификаторам, которые только моделируются неявно выше) и динамически вычисляют стоимость.

- EDIT -

Как говорит Доменик, ваш комментарий является хорошим кандидатом на последующий вопрос. Но я скажу, что после того, как вы получите идентификаторы task и worker на Contract, отчет становится тривиальной задачей.