阅读a SO question，我意识到我的阅读服务可以提供一些更智能的对象，例如ViewModels而不是普通的DTO。这使我重新考虑阅读服务返回的对象应提供哪些信息
在使用DTO之前，我的Read Service只是将数据库查询的平面视图映射到类似哈希的结构，具有最小的规范化和无行为。
但是，我倾向于将ViewModel视为“更智能”的东西，它可以生成数据库未提供的信息，如状态图标，计算值，重新格式化的值，默认值等。
我开始看到一些ViewModel对象的构造可能会变得更复杂并且如果我使我的泛型 ReadServiceInterface 仅返回ViewModels，则可能会有下降：
（1）我应该为CQRS返回的ViewModel计划一些设计限制吗？就像确保它们的结构几乎和普通DTO一样快？
（2）DTO本质上很容易被序列化并准备好发送到SOA架构中的外部系统或嵌入到消息中。这是否意味着使用ViewModels会对我的架构产生负面影响？
（3）我应该将哪种类型的ViewModel保留在我的读取服务之外？
（4）我是否应该从Read Services中检索所有ViewModel？
过去我实现了一些需要多个查询的ViewModel。在CQRS中，我认为，这是一种设计气味，因为它们提供的所有东西都只能在一个查询中。
我正在开始一个新项目，我认为任何查询都将返回聚合对象或DTO。从现在开始ViewModels发挥作用。我在想：
（5）我是否应该计划在我的架构中查询将产生两种类型的对象（ViewModels + Aggregates）或三种（+ DTO）？
答案 0 :(得分：7)
View Models（VM）为单个主服务器提供服务：View。我们通常认为VM是一个非常愚蠢的对象，所以在这方面，VM和DTO之间没有技术差异，只是它们的目的和语义不同。
如何构建VM是一个实现细节。某些VM预先生成并存储在VM存储库中。其他由服务（或查询处理程序）实时构建，可以通过直接查询数据库或查询其他存储库/服务然后汇总结果。没有对错，没有关于如何做的规则。归结为偏好。
在CQRS中，重要的部分是命令与查询的分离，即多个模型。关于您应该执行多少查询或者是否应该返回视图模型或dto，没有规则。只要您有至少一个专用于查询的读取模型，它就是CQRS。
不要让技术问题使您的设计复杂化。正确的设计更多的是关于高层结构而不是低层实现。使用CQRS是因为拥有阅读模型可以简化您的应用，而不是出于其他原因。旨在简化和清理代码，而不是用于规定“如何”配方的严格规则。