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

Question

假定读取模型ProductCatalogueItem是根据聚合/写入模型构建的，其中包含可出售的每种产品，具有以下属性：

• 基本：product_code，name，price，number_of_available_stock，
• 文档：short_description，description，...
• 产品特征：weight，length，depth，width，color，...

并且，有两个视图：

• 包含可用产品报价的列表/表格/网格的产品列表，并且视图仅需要以下基本属性：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)。

并且，控制器直接返回这些模型（或映射到dto进行传输层）。

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

---

2. ViewModels是ReadModels的另一个项目

读取服务将具有两种方法：

• List<ProductCatalogueItem> searchProducts(FilteringOptions)，
• ProductCatalogueItem getProduct(product_code)。

并且，从ReadModels到ViewModels的映射是由上层（可能是控制器）完成的。

过滤没有问题，...但是，还有另一个问题，即离开域层的数据多于实际需要的数据。并且，控制器将具有更多逻辑。由于针对不同的传输技术可能存在不同的控制器，因此映射代码可能会在这些控制器中重复。

---

根据DDD / CQRS，哪种组织职责的方法是正确的，或者完全是其他方法？

Answer 1

首先，您做出了错误的断言：

“ ...读取模型ProductCatalogueItem从聚合/写入模型中构建...”

读取模型不了解聚合或有关写入模型的任何信息，您可以直接从数据库构建读取模型，并返回UI所需的数据。

因此，视图模型是读取模型，它不影响写入模型。这就是为什么存在CQRS的原因：具有不同的模型（读取模型），以优化查询以返回客户端所需的数据。