user-interface - DDD/Presenter 模式 VS 用例最优查询

Question

在这伟大的book关于领域驱动设计，有一章专门介绍用户界面及其与领域对象的关系。

让我困惑的一点是Use case optimal queries和presenter之间的比较。

处理最佳查询的摘录(第 517 页)是:

Rather than reading multiple whole Aggregate instances of various types and then programmatically composing them into a single container (DTO or DPO), you might instead use what is called a use case optimal query.
This is where you design your Repository with finder query methods that compose a custom object as a superset of one or more Aggregate instances.
The query dynamically places the results into a Value Object (6) specifically designed to address the needs of the use case.
You design a Value Object, not a DTO, because the query is domain specific, not application specific (as are DTOs). The custom use case optimal Value Object is then consumed directly by the view renderer.

因此，优化查询的好处是直接提供特定于 View 的值对象，作为真正的 View 模型。

一页之后，描述了presenter模式:

The presentation model acts as an Adapter. It masks the details of the domain model by providing properties and behaviours that are designed in terms of the needs of the view.
Rather than requiring the domain model to specifically support the necessary view properties, it is the responsibility of the Presentation Model to derive the view-specific indicators and properties from the state of the domain model.

听起来这两种方式都实现了针对特定用例的 View 模型的构建。

目前我的调用链(使用 Play Framework)如下所示:

对于查询:Controllers(作为Rest接口(interface)发送Json)->Queries(通过最优查询返回具体值对象)

对于命令: Controller (作为 Rest 接口(interface)发送 Json)-> 应用程序服务(命令)-> 域服务/存储库/聚合(应用程序服务返回 void)

我的问题是:如果我已经练习了用例最优查询，那么实现演示者模式有什么好处？如果总是可以使用最佳查询来直接满足客户需求，为什么还要麻烦演示者呢？

我只是想到演示者模式的一个好处:处理命令，而不是查询，从而提供命令一些与演示者确定的 View 模型相对应的域对象。然后 Controller 将与域对象分离。事实上，Presenter 描述的另一个摘录是:

Additionally, edits performed by the user are tracked by the Presentation Model.
This is not the case of placing overloaded responsibilities on the Presentation Model, since it's meant to adapt in both directions, model to view and view to model.

但是，我更喜欢将纯原语发送到应用程序服务(命令)，而不是直接处理域对象，所以这个好处对我来说不适用。
有什么解释吗？

Answer 1

只是一个猜测:)

presenter 模式可以尽可能多地重用存储库的聚合查找器方法。例如，我们有两个 View ，在这种情况下我们需要两个适配器(每个 View 一个适配器)，但我们只需要一个存储库查找方法:

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)));

但最佳查询是面向 View 的(每个 View 一个查询)。我认为这两个解决方案是为 none-cqrs 风格的 ddd 架构设计的。在 cqrs 风格的架构中不再需要它们，因为查询不是基于存储库而是基于特定的薄数据层。