DDD/Presenter 模式 VS 用例优化查询

Posted 2023-02-23

【中文标题】DDD/Presenter 模式 VS 用例优化查询

【英文标题】：DDD / Presenter pattern VS Use case optimal query

【发布时间】：2014-01-14 08:01:42

【问题描述】：

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

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

处理最佳查询的摘录（第 517 页）是：

而不是读取各种不同的多个整体聚合实例 类型，然后以编程方式将它们组合到单个容器中 （DTO 或 DPO），您可以改用所谓的最佳用例 查询。 这是您使用查找器查询设计存储库的地方 将自定义对象组合为一个或多个超集的方法 聚合实例。 查询动态地将结果放入 值对象 (6) 专为解决使用需求而设计 案例。 您设计一个值对象，而不是 DTO，因为查询是 特定于域，而不是特定于应用程序（与 DTO 一样）。习俗 然后视图直接使用用例最优值对象 渲染器。

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

稍后一页，介绍者模式被描述：

表示模型充当适配器。它掩盖了细节 通过提供设计的属性和行为的领域模型 就视图的需求而言。 而不是要求 域模型专门支持必要的视图属性，它 表示模型的职责是导出 从域的状态查看特定的指标和属性 型号。

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

目前我的调用链（使用 Play 框架）如下所示：

对于查询：控制器（作为Rest接口发送Json）->查询（通过优化查询返回特定值对象）

对于命令：控制器（充当发送Json的Rest接口）->应用服务（命令）->域服务/存储库/聚合（应用服务返回void）

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

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

此外，用户执行的编辑由 演示模型。 这不是放置重载的情况 演示模型的责任，因为它是为了适应 在两个方向上，模型到视图和视图到模型。

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

【参考方案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)));

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

【讨论】：

我同意，这将是原因之一 :)