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

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

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

Отрывок, посвященный оптимальным запросам (стр. 517):

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

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

На следующей странице описывается шаблон ведущего:

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

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

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

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

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

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

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

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

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


user-interface architecture domain-driven-design presenter
person Mik378    schedule 26.12.2013    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

Шаблон 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 в стиле none-cqrs. Они больше не нужны в архитектуре в стиле cqrs, поскольку запросы основаны не на репозитории, а на конкретном тонком уровне данных.

person Yugang Zhou    schedule 27.12.2013
comment
Согласен, это одна из причин :) - person Mik378; 29.12.2013