Домен Driven Design (DDD) и сгенерированные с базы данных отчеты

Question

Я все еще изучаю DDD, но мне любопытно узнать об одной потенциальной ловушке.

В соответствии с DDD совокупный корень не должен знать о сохранении, но не означает ли это, что весь совокупный корень заканчивается тем, что создается в памяти?

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

Answer 1

В соответствии с DDD совокупный корень не должен знать о сохранении, но не означает ли это, что весь совокупный корень заканчивается тем, что создается в памяти?

О нет, это хуже, чем это; весь агрегат (корень и все подчиненные сущности) загружаются, создаются в памяти. По существу, по определению вам нужно все состояние, загруженное для проверки любых изменений.

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

Для этого вам не нужен агрегатный корень.

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

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

Answer 2

В соответствии с DDD совокупный корень не должен знать о сохранении, но не означает ли это, что весь совокупный корень заканчивается тем, что создается в памяти?

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

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

Агрегат не будет запрашивать базу данных для группировки и суммирования данных - как правило, вы загружаете агрегат в обработчик/службу приложений. Например:

public class SomeUseCaseHandler : IHandle<SomeCommand> 
{ 
    private readonly ISomeRepository _someRepository; 
    public SomeUseCaseHandler(ISomeRepository someRepository) 
    { 
     _someRepository = someRepository; 
    } 

    public void When(SomeCommand command) 
    { 
     var someAggregaate = _someRepository.Load(command.AggregateId); 
     someAggregate.DoSomething(); 
     _someRepository.Save(someAggregate); 
    } 
} 

Таким образом, ваш агрегат остается игнорировать, как он сохраняется. Однако ваша реализация ISomeRepository не не знает, поэтому может делать все, что необходимо для полной загрузки агрегата. Таким образом, вы могли бы иметь свою реализацию живучести группы/сумму при загрузке агрегата, но чаще вы, вероятно, запрос модели чтения:

public class SomeUseCaseHandler : IHandle<SomeCommand> 
{ 
    private readonly ISomeRepository _someRepository; 
    private readonly ISomeReadModel _someReadModel; 

    public SomeUseCaseHandler(ISomeRepository someRepository, ISomeReadModel readModel) 
    { 
     _someRepository = someRepository; 
     _someReadModel = someReadModel; 
    } 

    public void When(SomeCommand command) 
    { 
     var someAggregaate = _someRepository.Load(command.AggregateId); 
     someAggregate.DoSomethingThatRequiresTheReadModel(_someReadModel); 
     _someRepository.Save(someAggregate); 
    } 
} 

Вы на самом деле не сказали, что ваш случай использования, хотя. :)

[Update]

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