DDD / Presenter pattern VS Оптимальный вариант запроса

Question

В этой замечательной книге о доменно-управляемом дизайне глава посвящена пользовательскому интерфейсу и его связи с объектами домена.

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

Выдержка, касающаяся оптимальных запросов (стр. 517):

Вместо того, чтобы читать несколько целых экземпляров Aggregate различных типов и затем программно объединять их в один контейнер (DTO или DPO), вы могли бы вместо этого использовать так называемый оптимальный запрос варианта использования.
Здесь вы создаете свой репозиторий с помощью методов поиска, которые составляют пользовательский объект как расширенный набор из одного или нескольких агрегатных экземпляров.
Запрос динамически помещает результаты в объект Value (6), специально разработанный для удовлетворения потребностей варианта использования.
Вы создаете объект значения, а не DTO, потому что запрос зависит от домена, а не от приложения (как DTO). Объект оптимального значения пользовательского варианта использования затем используется средством визуализации представления.

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

Страница позже, образец презентатора описан:

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

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

В настоящее время моя цепочка вызовов (с использованием Play Framework) выглядит следующим образом:

Для запросов: Контроллеры (выполняющие роль интерфейса Rest, отправляющего Json) -> Запросы (возвращающие объект определенного значения через оптимальные запросы)

Для команд: Контроллеры (выполняющие роль интерфейса Rest, отправляющего Json) -> Службы приложений (Команды) -> Доменные службы / Репозитории / Агрегаты (службы приложений возвращают void)

Мой вопрос: если я уже практикую запрос оптимального варианта использования, какая польза от внедрения шаблона презентатора? Зачем беспокоиться о докладчике, если всегда можно использовать оптимальные запросы для непосредственного удовлетворения потребностей клиента?

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

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

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

Answer 1

Просто предположение:)

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

class CommentBriefViewAdapter {
    private Comment comment;

    public String getTitle() {
         return partOf(comment.getTitle()); 
         //return first 10 characters of the title, hide the rest
    } 
    .....//other fields to display
}

class CommentDetailViewAdapter {
    private Comment comment;

    public String getTitle() {
         return comment.getTitle();//return full title
    } 
    .....//other fields to display
}

//In controller:
model.addAttribute(new CommentBriefViewAdapter(commentRepo.findBy(commentId)));
// same repo method
model.addAttribute(new CommentDetailViewAdapter(commentRepo.findBy(commentId)));

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