aggregate - 事件存储根聚合与聚合

Question

事件存储中的“根聚合”和“聚合”有什么区别？

即使经过数小时的搜索，我也无法准确定义这些内容。我的理解是，聚合是一个 ID 表，通常将存储中的事件(集合)与对象表示组合在一起，这就是为什么也可以有聚合类型。

此外，我还看到过带有版本号的聚合表，在它们本质上是代表事件集合的组/容器/聚合 ID 的前提下，我发现这些表令人困惑。

Answer 1

因此，我们同意您正在尝试将事件流创建为 DDD 聚合根和聚合模式。

有一个常见的模式，即每个聚合都有自己的流。它具有聚合根的名称和标识，尽管名称部分不是必需的。

整个聚合上的所有操作都由事件表示，然后将事件写入此流。

因此，如果您有一个聚合根 MyNamespace.Order，它具有多个子值对象或实体 MyNamespace.OrderLine，则所有行上的操作都是通过访问聚合根来完成的方法和所有事件都写入一个流，因此对于 id 为 123 的订单，它将是:

流:我的名字

• 空间.Order-123
• 已下订单
• 订单送货地址集
• 已添加订单行
• 已添加订单行
• 订单行已删除
• 订单已确认
• 订单ETASet
• 订单已付款
• 订单已发货
• 订单已交付

实体的概念并未在事件存储端表示，因为您无法轻松定义不同流之间的关系以从多个流读取事件以重构聚合。因此，所有事件都在聚合根流中写入和读取，然后该根流成为整个聚合的流。

关于聚合的一个重要规则是聚合也是一致性边界。这基本上意味着聚合上的所有操作必须在一个事务中完成。

保留事件版本以处理并发非常重要。当您从事件存储中读取聚合时，您也会获得最新的事件版本。执行操作后，您写回新事件，检查最新事件版本是否仍然相同。如果最后一个事件版本不匹配，您将引发并发异常，因为有人已经在您之前更改了聚合并将更改写入存储，并且您遇到了冲突。

关于“表”，我不太清楚你的意思。当然，您可以在表中对事件存储进行建模，并且有不同的策略可以实现此目的。通常情况下，您确实更喜欢使用专门的事件存储，例如 this one .