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

【问题标题】：How to Model Complex Query Classes in CQRS如何在 CQRS 中为复杂的查询类建模
【发布时间】：2018-10-03 13:16:59
【问题描述】：

如何对查询类 (CQRS) 建模，因为数据是从各个地方累积的，然后在这些数据之上运行业务逻辑。目前，我们有代码可以提取 Manager 类中的所需数据和 Domain Model 中的业务逻辑。有没有更好的办法。高水平的建议会有所帮助。 Hiererachy 是 webapi Controller-> Manager -> DomainModel |-> Infrastructure(获取所需数据)

【问题讨论】：

啊——在不了解其含义并评估它们是否满足应用程序要求的情况下采用 cookie 模板架构的危害......您的实际用例是什么？
我们一般有 InMemory 缓存、DB 和 External HTTP API 作为数据源。对于任何搜索查询，我们必须查询这些源，然后在其上运行业务逻辑（例如，过滤) 然后返回数据。

标签： oop domain-driven-design cqrs

【解决方案1】：

一般来说，写入模型（从命令生成）不会镜像读取模型（从查询中获取）。

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

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

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

您的聚合可能仅通过引用 (id) 来引用其作者，而您的读取模型可能是扁平化的并且预先构建了您的 UI 所需的所有必要信息。

您最终会得到两个模型，其中您的 Aggregate 甚至不公开任何 getter（这是读取模型的目的）。

【讨论】：

【解决方案2】：

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

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

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

【讨论】：