Поиск дочерних объектов агрегатов в DDD

Question

В DDD корень агрегата является единственной ссылкой для извлечения его дочерних объектов.Репозиторий корневого агрегата отвечает только за предоставление ссылки на корневой объект.Если мне нужны дочерние объекты, необходимо вызвать метод получения агрегата для получения дочерних объектов, что приводит к запросу БД.

Рассмотрим случай, когда я получаю несколько агрегатов из БД.Так что в моем случае эта ситуация приводит к нескольким запросам БД, что приводит к очень медленному запросу.Как избежать этого с точки зрения DDD.Для настойчивости я наткнулся на шаблон под названием Unit Of Work.Есть ли шаблон для поиска, который решает мою проблему, или любой другой способ сделать это.

Answer 1

Прежде всего, 95% проблем решаются вашим ORM (если вы используете реляционную базу данных).

Агрегированный корневой репозиторий должен (в большинстве случаев) возвращать полностью загруженный объект со всеми дочерними объектами (сущностями). Ленивая загрузка детей должна быть исключением, а не правилом.

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

И рассмотрим решение для базы данных документов. Это действительно позволяет Sanes хранить целые агрегаты в виде документов в базе данных документов.

Answer 2

Ладно, похоже, у вас есть сценарий, в котором вы в одном случае хотите прочитать из нескольких AR, а также сохранить их состояние в БД. Операция чтения занимает много времени? или для чтения и записи требуется время?

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

Отчеты или другие операции, использующие большое представление данных, должны обходить модель предметной области. Не используйте DDD для отчетов и т. Д. Просто сделайте быстрый доступ к данным.

Во-вторых. Единица работы - это один из способов, если вы хотите, чтобы все агрегаты участвовали в транзакции.

В-третьих. Я бы сказал: используйте отложенную загрузку, но в некоторых случаях, когда требуется повышение производительности, вы можете использовать стратегию загрузки, которая означает, что вы позволяете корню загружать некоторые дочерние коллекции без запуска sql-sub-select ... посмотрите на эту статью http://weblogs.asp.net/fredriknormen/archive/2010/07/25/loading-strategy-for-entity-framework-4-0.aspx (даже для шаблона EF хорошо работает для NH ORM)

Тогда, наконец, вы всегда можете предоставить индексы БД, кеширование и т. Д., Чтобы повысить производительность, но, учитывая информацию о сценарии, вы получаете несколько неправильное решение. У меня нет всех фактов, но, возможно, некоторые варианты использования не подходят для