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。如果有，它会将Count增加一个。

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

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

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

Answer 1

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

是否重新移植方法当然会根据您的要求而有所不同，但一般的想法是正确的。

总结：

根据来自您网域的事件生成您的阅读模型（有时使用的官方用语为Eager Read Derivation）。

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

您所描述的SQL视图
按typeName分组的预聚合视图，这样您就不必每次在查询时都执行该组（而是在规范化程序中计算分组）。

简而言之，如何构建阅读模型没有正确或错误的方法。美丽正是你可以完全自由地模仿你以任何你想要的方式阅读模型（基于你想象的查询模式和性能瓶颈），而不必考虑这些模型如何影响写入（仅仅因为它们不会cqrs拆分读写）

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

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

使用Redis的INCR视图（这是您似乎描述的替代方案）
Elasticsearch / Solr搜索索引
按键进行快速查找的KV商店/索引。

再次提出想法，通过向他们推送更新事件（通常通过pubsub），这些'阅读模型'/视图始终保持最新（最终一致）

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

报告CQRS / ES世界

1 个答案: