Относительно структуры DDD и расслоения.

Question

Ребята, извинения, если это было описано в другой ветке, но я искал статьи ddd и mvc и не нашел прямого ответа.

Я надеюсь применить подход DDD к архитектуре моегоMVC проекты.Пожалуйста, исправьте меня, где я ошибаюсь.

Все действия контроллера MVC, которые включают в себя попадание в модель предметной области, первоначально попадут и на уровень обслуживания приложений.Уровень службы приложений здесь выступает в качестве фасада между представлением и доменом.Любые запросы от службы приложений, которые позже связаны с отдельными агрегатами домена, будут выполнять операции выборки или изменения корней агрегатов с использованием репозиториев.Каждый агрегатный корень будет иметь свой собственный репозиторий.

, поэтому на уровень службы приложений должны быть добавлены любые / все репозитории, требуемые доменом.

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

Мне это не кажется правильным.Моя путаница заключается в том, что с точки зрения DDD я не уверен, должны ли, например, агрегатные корни выполнять свое собственное постоянство, т. Е. Агрегат внедряется с репозиторием, а затем сохраняется / извлекает сам себя, или же, как указано выше, сервисный уровень приложения использует репозитории для обработки или выборки.агрегаты?

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

На этом этапе я не допускаю CQRS.,Я хочу сначала разобраться в уровнях и взаимосвязях между службами и агрегатами.

Спасибо за любой совет.

Answer 1

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

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

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

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

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

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

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

Да, я думаю, что это имеет смысл, особенно если доменная служба сильно зависит от репозитория.