Ответственность службы приложений против оптимизированных DTO

Question

Я чувствую себя застрявшим в моей разработке приложений MPA ABP между тремя принципами, которые я считаю DDD:

• Служба приложений не должна быть привязана к контроллеру.Я имею в виду, что контроллер не должен всегда использовать только один сервис приложений.Поскольку концепция службы приложений не имеет в виду представление .
• DTO должен соответствовать представлению, необходимому для минимизации передачи данных HTTP.Поэтому иногда нам приходится проектировать один класс DTO для каждой сущности / концепции и для представления .
• Прикладные сервисы получают и всегда возвращают DTO.

Теперь у меня есть представление, которое следует принципу Master-Detail: выберите одну сущность в Master-части из списка сущностей, загружая детали сущности в части Details с помощью Ajax-вызова.Но выбор сущности в мастер-части осуществляется с помощью Ajax-синхронизированного каскада раскрывающихся списков : ParentEntities> Entities.

Какой выбор лучше для DDD?

1. Поместить GetAllParent (), GetAllEntities (parentId) и GetEntity (id) все в MyViewApplicationService , тогда моя служба приложений можетвозвращать оптимизированные DTO для моих нужд, но нарушает принцип DDD ,
2. Поместите каждый из этих трех методов в различные сервисы приложений , выделив больше «домен»,но DTO являются предметно-ориентированными, несколько общими.Так что DTO не оптимизированы .
3. Пусть контроллер отвечает за сопоставление с DTO, которое соответствует потребностям вида, но он не должен этого делать .

Answer 1

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

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

• Службы приложений всегда получают и возвращают DTO.

Не всегда.Есть альтернативы DTO, как говорит Вон Вернон в своей книге «Внедрение DDD» (стр. 512):

• Посредник

• Объект полезной нагрузки домена

• Представления состояний

• Оптимальные запросы к хранилищу в оптимальном варианте использования (закрыто для CQRS)

• Преобразователи данных

Какой выбор лучше подходит для DDD?

1. Поместите GetAllParent (), GetAllEntities (parentId) и GetEntity (id) в MyViewApplicationService, а затем в службу приложений.может возвращать оптимизированные DTO для моих потребностей просмотра, но нарушает принцип DDD,

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

Поместите каждый из этих трех методов в разные прикладные сервисы, выделив больше «домен», но DTO ориентированы на домен, несколько общий.Таким образом, DTO не оптимизированы.

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

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

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

Answer 2

Я понимаю вашу проблему, я думаю, давайте начнем с начала:

... Поместите GetAllParent (), GetAllEntities (parentId) и GetEntity (id) все в MyViewApplicationService ...

Какое из этих слов поймет деловой человек?Являются ли какие-либо из этих слов частью вездесущего языка?

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

... но DTO ориентированы на предметную область, в некотором роде.Таким образом, DTO не оптимизированы ...

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

Тем не менее, если предполагается, что ваш объект ориентирован на домен, то почему он непригоден (не оптимизирован) для приложения, котороенаписано специально для этого домена?

Я думаю, проблема в том, что ваш "объект" фактически моделирует что-то отличное от домена.Вероятно, это моделирование таблицы базы данных или ее записей.

Я имею в виду, если вы показываете профиль для продукта, тогда ваш "объект" должен быть ProductProfile, а не универсальный Product.Или ProductDetails, или ProductHeroImage, и так далее. Эти вещи из домена и, вероятно, также упомянуты в документе с требованиями.

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

Почему бы не сделать это?Если цель вашей функции - показать пользователю некоторые данные, то почему это не считается «бизнес-функцией».Я имею в виду, что это должно быть буквально наоборот.«Представление» - это бизнес-функция, которую вы хотите, и база данных / хранилище / контроллер / служба или любая другая «просто» технология, которая должна быть просто деталью и невидима в архитектуре.

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