aggregate - CQRS 事件存储聚合与投影

Question

在 CQRS 事件存储中，“聚合”是否包含事件的汇总 View 或只是对这些事件边界的引用？ (组号)

投影是事件的 View 或表示，因此在聚合表示边界的情况下，这对我来说是有意义的，而如果聚合包含当前的汇总状态，我会对两者之间的重复感到困惑。

Answer 1

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)

在这种情况下，聚合仍然具有与 "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).

是的，没有。验证写入时使用的数据结构与用于支持查询的数据结构完全匹配。但存储通常不匹配。换句话说，聚合不会被存储(聚合的状态会存储)；而查询 View 被缓存是相当普遍的(同样，不是数据结构本身，而是一种可用于重新填充数据结构而不必重播所有事件的表示形式)。

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 存储中，这可能看起来像 books 表中的一行，具有该书的唯一 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.

是的，完全正确。如果您熟悉“折叠函数”，那么事件溯源只是一些常见初始状态的折叠。当快照可用时，我们将从该状态折叠(相应减少折叠的事件数量)

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