domain-driven-design - 在 DDD/CQRS 中，ReadModel 是否应该充当 ViewModel，如果不是，那么映射的责任在哪里？

Question

假设读取模型 ProductCatalogueItem由聚合/写入模型构建，与写入模型分开存储，包含每个可供销售的产品，并具有以下属性:

• 基础知识:product_code , name , price , number_of_available_stock ,
• 文档:short_description , description ,...
• 产品特性:weight , length , depth , width , color ,...

并且，有两种观点:

• 产品列表包含可用产品报价的列表/表格/网格， View 只需要以下基本属性:product_code , name , price , number_of_available_stock ,
• 显示所有属性的产品详细信息 - 基础知识、文档、产品特性。

自然地，想到了两个 ViewModel:

• ProductCatalogueListItem仅包含基本属性，
• ProductCatalogueItemDetails包含所有属性。

现在，.. 有两个选项(我可以看到)。

---

1. ViewModels 是 ReadModels 的 1:1 表示

因此有两个读取模型，而不是一个，ProductCatalogueListItem和 ProductCatalogueItemDetails .并且，读取服务将有两种方法:

• List<ProductCatalogueListItem> searchProducts(FilteringOptions) ,
• ProductCatalogueItemDetails getProductDetails(product_code) .

并且， Controller 直接返回这些模型(或者，映射到传输层的 dto)。

这里的问题是过滤，..读取服务是否应该在不同的读取模型上执行搜索查询，而不是从方法调用返回？因为，ProductCatalogueListItem 没有足够的信息来执行过滤。

---

1. ViewModels 是 ReadModels 的另一个项目

读取服务有两种方法:

• List<ProductCatalogueItem> searchProducts(FilteringOptions) ,
• ProductCatalogueItem getProduct(product_code) .

并且，从 ReadModels 到 ViewModels 的映射是由上层(可能是 Controller )完成的。

过滤没有问题，...但是，还有另一个问题，即离开域层的数据比实际需要的多。而且， Controller 会随着更多的逻辑而增长。由于不同的传输技术可能有不同的 Controller ，因此映射代码可能会在这些 Controller 中重复。

---

根据 DDD/CQRS，哪种组织职责的方法是正确的，还是完全不同？

重点是:

• 我应该构建两个阅读模型，使用一个进行搜索，然后返回另一个吗？
• 我是否应该构建使用的单读模型，然后映射到有限 View 以仅包含 View 的基本信息？

Answer 1

首先，你做了一个错误的断言:

...read model ProductCatalogueItem is built from aggregates/write-models...

读取模型不知道聚合或任何关于写入模型的信息，您直接从数据库构建读取模型，返回 UI 所需的数据。

因此， View 模型是读模型，它不涉及写模型。这就是 CQRS 存在的原因:为了拥有不同的模型，即读取模型，以优化返回客户端所需数据的查询。

更新

我会尝试更好地解释自己:

CQRS 只是根据方法类型将一个对象一分为二。有两种方法类型:命令(任何改变状态的方法)和查询(任何返回值的方法)。就这样。

当您将此模式应用于应用程序的服务边界时，您将拥有一个写入服务和一个读取服务，因此您可以以不同方式扩展命令和查询处理，并且您还可以拥有两个模型。

但 CQRS 没有两个数据库，不是消息传递，不是最终一致性，不是从写入模型更新读取模型，不是事件源。您可以在没有它们的情况下执行 CQRS。我这样说是因为我在您的断言中发现了一些误解。

也就是说，读取模型的设计是根据用户希望在UI中看到什么信息来完成的，即读取模型是 View 模型，它们之间没有映射关系，它们是同一个模型.您可以在下面的引用文献 (3) 和 (6) 中阅读相关信息。我认为这是对你整个问题的回答。我不明白的是过滤问题。

一些好的引用资料

(1) http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/

(2) http://www.cqrs.nu/Faq/command-query-responsibility-segregation

(3) “实现领域驱动设计”一书，作者 Vaughn Vernon。第 4 章:架构，“命令-查询责任分离，或 CQRS”部分

(4) https://kalele.io/really-simple-cqrs/

(5) https://martinfowler.com/bliki/CQRS.html

(6) http://udidahan.com/2009/12/09/clarified-cqrs/