如何在CQRS中为复杂的查询类建模

Question

如何对查询类（CQRS）进行建模，假设数据是从各个地方累积的，然后在此数据之上运行业务逻辑。当前，我们有代码来提取Manager类中的必需数据和Domain Model中的业务逻辑。有没有更好的办法。高水平的建议会有所帮助。 Hiererachy是webapi控制器->管理器-> DomainModel |->基础结构（用于获取所需数据）

Answer 1

通常来说，写入模型（从Commands生成）不会镜像读取模型（从查询中获取）。

写入模型（聚合根）旨在确保域的一致性和不变性，而读取模型主要用于构建UI和/或API。

如果您为Blog设计一个简单的域，则可能具有Post聚合和PostSummary以及PostDetails甚至是简单的Post。

两者的名称相似，但使用环境不同。

您的聚合可能仅通过引用（id）来引用其作者，而您的阅读模型可能已被展平并预先构建了UI所需的所有必要信息。

您最终得到了两个模型，这些模型的聚合甚至没有暴露任何吸气剂（这是读取模型的目的）。

Answer 2

听起来您只在做CQRS的C部分，而不是Q。在CQRS中，有2种数据模型，一种是通过命令（写模型）更新的，一种是为显示目的而定制的。 （读取模型）。当命令对数据进行更改时，它将使用写入模型中的业务规则加载完整的汇总，进行适当的更改并保存。然后，它（通常通过发送消息）请求更新读取的模型。

读取模型是为特定目标UI页面定制构建的表的集合。数据复制无处不在。想法是读取应该非常快，因为它们只是读取表中的“ select *”查询。

如果您实现了读取模型，那么您的问题就没有意义了，因为没有复杂的查询类。如果您尚未实现CQRS，则将采用常规建议，例如创建存储库以包含查询等。