在CQRS活动商店中，＆＃34;聚合＆＃34;包含事件的摘要视图或仅仅是对这些事件边界的引用？ （组ID）
投影是事件的视图或表示，因此在聚合表示对我有意义的边界的情况下，而如果聚合包含当前的概括状态，则我对两者之间的重复感到困惑。
答案 0 :(得分：19)
在CQRS事件存储中，“聚合”是否包含事件的汇总视图或仅仅是对这些事件边界的引用？ （组ID）
事件存储中不存在聚合
在这种情况下，聚合仍具有与"Blue Book"中相同的基本含义;它是围绕一个或多个实体的边界的术语，这些实体彼此立即一致。聚合的责任是确保对记录簿的写入（命令）尊重业务不变量。
在事件存储中，将事件组织成“流”通常很方便;如果您想象一个RDBMS schema，则流ID将只是一些标识符，表示“这些事件都属于同一历史记录。”
通常情况是一个聚合 - ＆gt;一条流，但通常并不总是;在更改模型时，您可能需要处理一些特殊情况。 Greg Young在他的新eBook on event versioning中介绍了其中一些内容。
因此，聚合和查询端存储中可能存在相同的数据结构（用于不同目的的重复视图）。
是的，不。绝对的情况是，验证写入时使用的数据结构与用于支持查询的数据结构相匹配。但存储通常不匹配。换句话说，聚合不会被存储（聚合的状态）;然而，查询视图被缓存（相反，不是数据结构本身，而是可用于重新填充数据结构而无需重放所有事件的表示）是相当普遍的。
您是否有机会获得聚合状态数据结构（rdbms）的示例？我发现的每个例子都被删减到几列，包括包含id，source_id，版本，这使得很难看出聚合的范围是什么
一个常见的例子是交易账簿（负责匹配“买入”和“卖出”订单的汇总）。
在传统的RDBMS商店中，它可能看起来像书籍表中的一行，具有书籍的唯一ID，关于该书正在跟踪的项目的信息，关于该书何时处于活动状态的日期信息，等等。此外，可能存在某种订单表，包括uniq ID，交易账户ID，订单类型，交易编号，价格和交易量（换句话说，汇总需要知道的所有信息以满足其不变量）
在文档存储中，您可以在单个文档中看到所有这些信息 - 可能是包含有关根对象信息的json文档，以及两个订单对象列表（一个用于购买，一个用于销售）。
在活动商店中，您会看到个人OrderPlaced，TradeOccurred，OrderCancelled。
似乎聚合是使用整个事件集计算的，除非它足够大以保证快照。
是的，这是完全正确的。如果您熟悉“折叠功能”，那么事件来源只是一些常见初始状态的折叠。当快照可用时，我们将从该状态折叠（相应减少折叠的事件数量）
在具有“快照”的事件源环境中，您可能会看到事件存储和文档存储的组合（其中文档将包含指示事件流在何处组装的其他元信息）。