CQRS事件存储聚合与投影

In a CQRS event store, does an “aggregate” contain a summarized view of the events or simply a reference to the boundary of those events? (group id)

事件存储中不存在聚合

>活动现场直播

>聚合生活在写模型中(CQRS的C)

在这种情况下,Aggregate仍具有与 “Blue Book” 中相同的基本含义;它是围绕一个或多个实体的边界的术语,这些实体彼此立即一致.聚合的责任是确保对记录簿的写入(命令)尊重业务不变量.

在事件存储中,通常方便地将事件组织成“流”;如果您想象一个 RDBMS schema ,则流ID将只是一些标识符,表示“这些事件都是同一历史记录的一部分”.

通常情况是一个聚合 – >一条小溪,但通常并不总是;在更改模型时,您可能需要处理一些特殊情况. Greg Young在他的新 eBook on event versioning 中报道了其中一些.

So it’s possible that the same data structure might exist in the aggregate and query side store (duplicated view used for different purposes). 

是的,不.绝对是在验证写入时使用的数据结构与用于支持查询的数据结构匹配的情况.但存储通常不匹配.换句话说,聚合不会被存储(聚合的状态);然而,查询视图被缓存(相反,不是数据结构本身,而是可用于重新填充数据结构而无需重放所有事件的表示)是相当普遍的.

Any chance you have an example of aggregate state data structure (rdbms)? Every example I’ve found is trimmed down to a few columns with something like include id, source_id, version making it difficult to visualize what the scope of an aggregate is

一个常见的例子是交易账户(负责匹配“买入”和“卖出”订单的汇总).

在传统的RDBMS商店中,它可能看起来像书籍表中的一行,具有书籍的唯一ID,关于该书正在跟踪的项目的信息,关于该书何时活动的日期信息,等等.此外,可能存在某种订单表,包括uniq id,交易账户ID,订单类型,交易编号,价格和交易量(换句话说,汇总需要知道的所有信息以满足其不变量) .

在文档存储中,您可以在单个文档中看到所有这些信息 – 可能是包含有关根对象信息的json文档,以及两个订单对象列表(一个用于购买,一个用于销售).

在事件存储中,您将看到单个OrderPlaced,TradeOccurred,OrderCancelled.

it seems that the aggregate is computed using the entire set of events unless it gets large enough to warrant a snapshot.

是的,这是完全正确的.如果您熟悉“折叠功能”,那么事件采购只是一些常见初始状态的折叠.当快照可用时,我们将从该状态折叠(相应减少折叠的事件数)

在具有“快照”的事件源环境中,您可能会看到事件存储和文档存储的组合(其中文档将包含指示事件流在何处组装的其他元信息).