cqrs - CQRS/ES 世界中的报告

Question

我想我理解了 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 专家会同意吗？这是做事的“方式”吗(即创建这些专用的报告读取模型)？非常感谢任何对源代码/真实示例的引用。

Answer 1

Is this the acceptatble reporting approach?

是否是 报告方法当然因您的要求而异，但总体思路是正确的。

总结:

您根据来自您域的事件生成您的读取模型(有时使用的官方术语是 Eager Read Derivation)。

读取模型可以是任何你想要的(sql、redis、mongo 等)。任何使您的查询具有高性能的东西。例如，在您的示例中，您没有理由不能拥有 2 个读取模型来更有效地进行查询(尽管您所描述的对于大多数情况来说可能已经足够):

1. 您的 sql View 如所描述的那样
2. 按 typeName 分组的预聚合 View ，这样您就不必每次都在查询时进行分组(而是在规范器中计算分组)。

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

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

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

• Redis 的 INCR View (这与您描述的内容不同)
• Elasticsearch/Solr 搜索索引
• KV 存储/索引，用于按键快速查找。

我的想法是，通过向它们推送更新事件(通常通过 pubsub)，这些“读取模型”/ View 始终保持最新(最终保持一致)

要获得更多好的阅读，请参阅答案以及此问题的链接: Read side implementation approaches using CQRS