DDD - А как насчет пользовательских SQL-запросов для нескольких агрегатов в одном методе хранилища?

Question

Я разрабатываю свои агрегаты для обеспечения соблюдения инвариантов и бизнес-правил. Я всегда рассматриваю свой агрегат как «модель записи» / «модель транзакции».

Учитывая это, я всегда могу свободно показывать «сложные» методы GET в своих репозиториях, используя пользовательский SQL / Linq, потому что я не изменяю данные.

Например, рассмотрим два фиктивных совокупных корня (ученик и школа), используя только ссылочные идентификаторы между ними. Если я хочу отправить электронное письмо всем учащимся школы, я обычно использую службу домена, которая выполняет это, для повышения производительности:

1. Вызывает репозиторий с помощью метода, подобного «GetAllStudentEmailAddressesForSchool (Guid schoolId)»
2. Отправляет электронное письмо каждому ученику

Конечно, реализация репозитория должна была бы выполнить «сложный» запрос (JOIN) для двух агрегатов.

Типичной альтернативой может быть организация нескольких вызовов в репозитории в доменной службе:

1. Выбрать школу из репозитория ISchool
2. Foreach StudentId Школы, позвоните в IStudentRepository

(Конечно, это зависит от совокупного моделирования, но основная концепция остается).

У меня было много споров с коллегами по этому поводу, многие утверждают, что первый подход пропускает бизнес домена вне домена (он же на уровне инфраструктуры, в реализации репозитория).

Для меня это простая стратегия фильтрации, аналогично тому, как ISchoolRepository представляет такой метод, как «GetSchoolsFromCity (Guid cityId)». Тот факт, что фильтрация выполняется для одного агрегата вместо двух, ничего не меняет.

Есть мнения по этому поводу?

Answer 1

вам не нужно использовать доменную модель, то есть агрегаты, при реализации запроса. Вы можете запросить базу данных и извлечь нужные данные в простой пользовательский dto в соответствии с нужными вам данными. Таким образом, вы разделяете модель записи и модель Resd.

Answer 2

Во-первых, не зацикливайтесь на идеальном способе взаимодействия агрегатов. Часто нет единственного правильного ответа, только куча неправильных.

Во-вторых, вы описали свои агрегаты и репозитории, но не свой ограниченный контекст (ы). Из того, что я знаю о школах, довольно трудно иметь школу, в которой нет учеников. Как ты смоделировал это?

Наконец, как вы заявили, это read модели. Прекрасно иметь запрос LINQ, который получает все электронные письма учеников для данной школы. Отправьте этот результат в службу, которая отправляет электронные письма и поддерживает их.