DDD - агрегированная загрузка корня / производительность запросов

Я играю с DDD, и этот вопрос всплывает. Как загрузить дочерние агрегированные корни? Возникло бы несколько проблем с производительностью. Представьте себе следующий пример:

public AggregateRoot1
{
     #region
        properties
     #endregion

     public AggregateRoot2 AR2{get;set;}

     public IEnumerable<AggregateRoot3> AR3List{get;set;}

     (...)
}

Если я загружу список AggregateRoot2 и AggregateRoot3, когда получу AggregateRoot1, график будет огромным. Это не кажется хорошим подходом.

У меня есть два варианта:

  1. Замените AggregateRoot2 AR2 на Guid AR2Id и IEnumerable AggregateRoot3> AR3List на IEnumerable Guid> AR3ListIds. Все ссылки AR должны быть заменены идентификатором.
  2. Поскольку мне не нравится подход IEnumerable ARListIds, я думаю об удалении 0 ... * ссылок на AR. Все операции, для которых требуются данные списка AR, должны выполняться через службы домена, такие как David Masters, здесь

Кстати, я не собираюсь использовать ленивую загрузку.

Я с нетерпением жду вашего мнения о загрузке дочерней AR. Спасибо


cqrs domain-driven-design aggregateroot ddd-repositories
person JPP    schedule 13.03.2013    source источник

Ответы (2)


arrow_upward
7
arrow_downward

В идеале ссылки между агрегатами должны быть только идентичными. Это вариант 1. Однако вам следует оценить каждую ссылку, чтобы увидеть, требуется ли она для согласованности агрегата хранения ссылок. Иногда связь между двумя агрегатами может быть сделана агрегатом, загружаемым по отдельности. В целом, взгляните на Эффективный агрегированный дизайн Вона Вернона для более глубокого анализа различных компромиссов. при проектировании агрегатов. На это также указывает Дэвид Мастерс в связанном вопросе.

person eulerfx    schedule 13.03.2013
comment
@ eulerfx-Спасибо за ответ. Я согласен со ссылкой на другой совокупный корень с идентификатором, но как насчет коллекции AR. Следует преобразовать в массив идентификаторов AR? Я никогда не видел подобной реализации, примеры, которые я вижу, представляют собой только отношения 1-1. - person JPP; 13.03.2013
comment
Более того, поскольку Guids не являются частью повсеместного языка, если они вам действительно нужны для обеспечения бизнес-инвариантов, вы должны использовать общие идентификаторы. - person Giacomo Tesio; 13.03.2013
comment
Подойдет коллекция идентификаторов AR, посмотрите здесь: github.com/MarkNijhof/Fohjin - person eulerfx; 13.03.2013
comment
Я согласен с eulerfx и хочу добавить, что я не думаю, что загрузка всего графа объекта является большой проблемой в целом, поскольку это то, что делает большинство контейнеров DI, если только эти объекты не загружают огромные объемы данных из сети или жесткого диска. - person Ibrahim Najjar; 14.03.2013

arrow_upward
0
arrow_downward

Если графики становятся слишком массивными и вы не можете использовать отложенную загрузку, это, вероятно, признак того, что ваша модель может потребовать некоторой работы - у вас, вероятно, есть объекты, которые должным образом должны быть собственными агрегированными корнями.

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

Одна из причин следовать DDD - это инкапсуляция сложности. Но наличие идентификаторов некорневых объектов нарушает эту инкапсуляцию. Хотя могут быть проблемы с производительностью, преждевременная оптимизация кода для повышения производительности не всегда приводит к созданию хорошего программного обеспечения.

person Mathieson    schedule 13.03.2013
comment
Я согласен с вами, но суть вопроса в том, что у вас есть ссылки на корень дочерних агрегатов, или ваш агрегированный корень никогда не имеет ссылок на другой агрегатный корень? Дело в загрузке дочернего агрегатного корня. - person JPP; 14.03.2013