我想我理解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专家会同意吗?这是'方式'做事(即创建这些专用的报告阅读模型)?任何对源代码/真实示例的引用都将非常感激。
答案 0 :(得分:4)
这是可接受的报告方法吗?
是否 重新移植方法当然会根据您的要求而有所不同,但一般的想法是正确的。
总结:
根据来自您网域的事件生成您的阅读模型(有时使用的官方用语为Eager Read Derivation)。
读取的模型可以是你想要的任何东西(sql,redis,mongo等)。无论如何都能使您的查询具有高效性。例如,在您的示例中,您没有理由不能使用2个读取模型来更有效地执行查询(尽管您所描述的内容在大多数情况下可能已足够):
typeName
分组的预聚合视图,这样您就不必每次在查询时都执行该组(而是在规范化程序中计算分组)。简而言之,如何构建阅读模型没有正确或错误的方法。美丽正是你可以完全自由地模仿你以任何你想要的方式阅读模型(基于你想象的查询模式和性能瓶颈),而不必考虑这些模型如何影响写入(仅仅因为它们不会cqrs拆分读写)
将事件源与CQRS结合使用可以提供更好的可能性,即创建新的读取模型,并通过重放事件源中的过去事件来填充数据。
可能被视为数据的“阅读模型”的一些额外示例:
再次提出想法,通过向他们推送更新事件(通常通过pubsub),这些'阅读模型'/视图始终保持最新(最终一致)
要获得更好的阅读,请参阅答案以及此问题的链接: Read side implementation approaches using CQRS