Я согласен с вами, что концепция совокупных корней может сбивать с толку, пока вы не решите ее. Как и большинство других концепций, с практикой это становится проще, прорабатывая это несколько раз.
Суть агрегата заключается в упрощении обхода объекта для некоторого внешнего объекта в контексте одного или нескольких вариантов использования . Вы должны начать где-то , чтобы удовлетворить бизнес-требования, и если вы обнаружите, что вам в значительной степени нужен журнал, это похоже на то, что он на самом деле должен быть объединенным корнем. В большинстве доменов, которые не являются тривиальными, вам будет полезно иметь более одного совокупного корня. В исходном объекте для варианта использования нет ничего сверхъестественного. Вам просто нужно с чего-то начать.
Но опять же, смысл в том, чтобы упростить обход объектов, что упрощает вашу систему. Так что, если журнал на самом деле является полезной отправной точкой, сначала сделайте все ваши звонки в журнал. Если в конкретном случае использования потребуются Задачи, Деньги, Время или любые другие полезные вещи, вызывающая программа получает эти вещи, запрашивая журнал, и только журнал. Другие объекты являются частью объединенного корня журнала, для этого варианта использования.
Для других вариантов использования может быть более естественным и поэтому полезным, чтобы Задача была отправной точкой, и поэтому у вас также может быть корень агрегата Задачи, который, скорее всего, будет перекрывать ваш корень агрегата журнала. Но вы просите Задачу и только Задачу удовлетворить запрос (быть единственной ссылкой, о которой должна знать вызывающая программа)
Ваш реляционный БД может и будет оставаться реляционным, конечно. Но благодаря тому, что ваша объектная модель будет развиваться, чтобы рассматривать запросы с точки зрения совокупности (объект начальной точки), ваши запросы из БД будут проще.
Выложите вариант использования (или два) и попробуйте его проработать. Задавайте вопросы в контексте варианта использования, если хотите.
НТН,
Berryl