MVC DDD EF Сложный обход детского объекта

Question

У меня есть дебаты по работе с совокупными корнями и с использованием навигационных свойств для перемещения по дочерним объектам.

Сценарий 1:

• клиента совокупный корень
• Адрес является юридическим лицом
• Контакт является объектом

Клиент может иметь несколько адресов и адрес может быть несколько контакты. Я запрашиваю репозиторий клиентов ниже, используя идентификатор клиента и возвращаю объект клиента.

Dim customer as Customer = _customerRepository.GetById(request.Id) 

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

Dim address as Address = customer.RetrieveAddress(request.AddressId) 

Этот подход будет затем перенесен на x число дочерних объектов. Пример, который я показал, является простым, но с точки зрения таблиц БД, содержащих миллионы записей, как другие люди справлялись с проблемами производительности при прохождении нескольких дочерних объектов после того, как агрегированный корневой объект был помещен в очередь и возвращен?

Сценарий 2:

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

Dim address as Address = _customerRepository.GetAddressById(request.AddressId) 

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

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

Просто интересно, как другим людям удалось применить DDD полностью без снижения производительности, поскольку при использовании EF с навигационными свойствами, как только вы их используете, он отправляет запрос для каждого дочернего объекта, который потенциально отправляет 100+ запросов, если он в цикле for.

Майк

Answer 1

Агрегаты - сложный бизнес, и решение об общих границах требует много размышлений. Читая свой вопрос, я не совсем уверен, что вы разрабатываете свои агрегаты на основе поведения, а не связей сущности DB. Как говорит Эбен, вы не получите очень далеко от последнего подхода, и ваши агрегаты, вероятно, окажутся довольно большими (с точки зрения количества дочерних объектов).

Одна из самых проницательных вещей, которые я прочитал на эту тему, - Effective Aggregate Design by Vaughn Vernon. Я определенно рекомендую дать ему прочитать. Одна важная вещь, о которой он говорит, пытается сделать ваши агрегаты как можно меньше. Это, естественно, поможет в производительности.

Для детей Объекты Я бы не сделал то, что вы сделали в сценарии 2, потому что вы не должны мутировать состояние объекта, не делая этого через корень заполнителя; это поддерживает инварианты. Сказав это, ваш пример использует адресный объект, который, вероятно, будет объектом значения, поэтому наличие отдельного хранилища адресов по соображениям производительности будет в порядке.

Когда вы начинаете с DDD, я думаю, что важно помнить, что вам все еще нужно быть прагматичным в выборе дизайна; DDD не решает все ваши проблемы для вас. В большинстве случаев выбор дизайна является компромиссом для таких вещей, как производительность.

Answer 2

Вы не сможете получить очень далеко, используя диаграмму ER для определения агрегатов :)

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

Natural vs. Synthetic Aggregates

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