DDD /演示器模式与用例优化查询

Question

在这个关于领域驱动设计的伟大的书中，有一章专门讨论用户界面及其与域对象的关系。

让我困惑的一点是用例优化查询和演示者之间的比较。

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

与其读取各种类型的多个整体聚合实例，然后以编程方式将它们组合到单个容器(DTO或DPO)中，不如使用所谓的用例优化查询。 这是您使用finder查询方法设计Repository的地方，这些方法将自定义对象组合为一个或多个聚合实例的超集。 该查询动态地将结果放入一个值对象(6)中，该值对象(6)专门设计以满足用例的需求。 您设计的是一个值对象，而不是DTO，因为查询是特定于域的，而不是特定于应用程序的(就像DTO一样)。然后视图呈现器直接使用自定义用例优化值对象。

因此，优化查询的好处是直接提供特定的对视图的值对象，充当真正的视图模型。

在后面的页面中，将描述演示者模式：

表示模型充当适配器。它通过提供根据视图需求设计的属性和行为来掩盖域模型的细节。 表示模型没有要求域模型专门支持必要的视图属性，而是从域模型的状态派生视图特定的指示符和属性。

听起来，这两种方法都实现了特定于用例的视图模型的构建。

目前，我的调用链(使用Play Framework)看起来如下：

对于查询:控制器(充当Rest接口发送Json) ->查询(通过优化查询返回特定值对象)

用于命令:控制器(充当Rest接口发送Json)、->应用程序服务(命令)、->域服务/存储库/集合(应用程序服务返回无效)

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

我只是想到了演示者模式的一个好处:处理命令，而不是查询，从而提供命令来命令与演示者确定的视图模型相对应的一些域对象。然后控制器将与域对象解耦。事实上，另一段推荐人描述的摘录是：

此外，用户执行的编辑由表示模型跟踪。 这不是将重载的责任放在表示模型上的情况，因为它的目的是在两个方向上进行调整，即从模型到视图，从视图到模型。

但是，我更喜欢将纯原语发送到应用程序服务(命令)，而不是直接处理域对象，因此这种好处不会适用于我。

有什么解释吗？

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

但是最优的查询是面向视图的(每个视图都是一个查询)。我认为这两种解决方案都是为无cqrs风格的ddd架构而设计的。因为查询不是基于存储库，而是基于特定的瘦数据层，所以在cqrs风格的结构中不再需要它们。