CQRS/ES 世界中的报告

我想我理解 ES + CQRS 背景下的读取模型的想法（如果不明白请纠正我）。然而，我对于在“严肃”报道的背景下使用它仍然有一些疑问。假设我使用关系数据库加上一些 ORM 来整理我的读取模型。一个基本的“摘要统计读取模型”可能如下所示：

 class SummaryStats1
    {
    public Guid TypeId { get; set; }
    public string TypeName { get; set; }
    public Guid SubTypeId { get; set; }
    public string SubTypeName { get; set; }
    public int Count { get; set; }
    }

给定一个事件：

TypeId = 3acf7d6f-4565-4672-985d-a748b7706a3e
TypeName = Bla1
SubTypeId = 41532aa1-f5d1-4ec4-896b-807ad66f75fc
SubTypeName = Bla2

标准化器将：

(1) 检查是否存在上述组合的实例（由TypeId、TypeName、SubTypeId、SubTypeName定义） (2) 如果没有实例，它将创建一个实例并将 Count 设置为 1。如果有的话，计数就会加一。

这是可接受的报告方法吗？我想人们可以针对这种非规范化的数据结构运行非常有效的选择（用于过滤和其他 sql“投影”）：

SELECT  TypeName, Sum(Count) FROM SummaryStats1 GROUP BY TypeName

CQRS/ES 专家会同意这一点吗？这是做事的“方式”吗（即创建这些专用的报告读取模型）？任何对源代码/真实示例的引用都将非常感激。

这是可接受的报告方法吗？

无论是the报告方法当然会根据您的要求而有所不同，但总体思路是正确的。

总之：

您生成读取模型（有时使用的官方术语是热切阅读推导 http://martinfowler.com/bliki/EagerReadDerivation.html）基于来自您的域的事件。

读取模型可以是您想要的任何模型（sql、redis、mongo 等）。无论什么都能使您的查询保持高性能。例如，在您的示例中，您没有理由不能使用 2 个读取模型来更有效地执行查询（尽管您所描述的内容对于大多数情况来说可能就足够了）：

1. 你的 sql 视图如所描述的
2. 预先聚合的视图分组typeName这样您就不必每次在查询时都进行分组（而是在标准化器中计算分组）。

简而言之，构建阅读模型的方法没有正确或错误之分。美妙之处在于，您可以完全自由地以任何您想要的方式（基于您设想的查询模式和性能瓶颈）对您读取的模型进行建模，而不必考虑这些模型如何影响写入（仅仅是因为它们从那时起就不会影响写入） cqrs 拆分读取和写入）

将事件源与 CQRS 结合使用可以提供更好的可能性，即创建新的读取模型并通过从事件源重播过去的事件来简单地用数据填充它们。

只是一些可能被视为数据“读取模型”的额外示例：

• Redis 的 INCR 视图（这是您似乎描述的替代方案）
• Elasticsearch / Solr 搜索索引
• 用于按键快速查找的 KV 存储/索引。

再次的想法是，通过向它们推送更新事件（通常通过 pubsub ），这些“读取模型”/视图始终保持最新（最终一致）

要获得更多好的阅读内容，请参阅答案以及此问题的链接：使用 CQRS 的读取端实现方法 https://stackoverflow.com/questions/15934490/read-side-implementation-approaches-using-cqrs?rq=1