事件存储中的“根聚合”和“聚合”有什么区别？
即使经过数小时的搜索，我也无法准确定义这些内容。我的理解是，聚合是一个 ID 表，它将商店中的事件（集合）组合在一起，通常带有对象表示，这就是为什么也可以有聚合类型的原因。
此外，我还看到了带有版本号的聚合表，我觉得在它们本质上是代表事件集合的组/容器/聚合 ID 的前提下感到困惑。
【问题讨论】：
标签： aggregate cqrs event-sourcing
因此，我们同意您尝试将事件流制作为 DDD 聚合根和聚合模式。
每个聚合都有自己的流，这是一种常见的模式。它具有聚合根的名称和标识，尽管名称部分不是必需的。
整个聚合上的所有操作都由事件表示，然后写入此流。
所以如果你有一个聚合根MyNamespace.Order，它有多个子值对象或实体MyNamespace.OrderLine，所有行上的操作都是通过访问聚合根方法完成的，所有事件都写入一个流，所以对于订单使用 id 123 将是：
流：我的名字
实体的概念没有在事件存储方面表示，因为您无法轻松定义不同流之间的关系以从多个流中读取事件以重新组合聚合。因此，所有事件都在聚合根流中写入和读取，然后成为整个聚合的流。
关于聚合的一个重要规则是聚合也是一致性边界。这基本上意味着对聚合的所有操作都必须在一个事务中完成。
保持事件版本以处理并发性很重要。当您从事件存储中读取聚合时，您也会获得最新的事件版本。执行该操作后，您将新的事件写回，检查最新的事件版本是否仍然相同。如果最后一个事件版本不匹配，您会抛出并发异常，因为有人已经更改了聚合并在您之前将更改写入存储并且您遇到了冲突。
关于“表格”，我不太清楚你的意思。当然，您可以在表中建模您的事件存储，并且有不同的策略来执行此操作。更多的时候，你真的不喜欢使用专门的事件存储，比如this one。
【讨论】：
DDD 书籍和条款并未专门针对事件溯源（它还不是 A Thing）。
SE Radio podcast 226 with Eric Evans 稍微介绍一下。
聚合是一组相关的实体和值对象，聚合模拟需要保持内部一致的单个事物（或相关的事物集）
聚合根可以是“通过”查看聚合的根实体（例如，您拥有它的发票实体和一组单独的订单行）
不幸的是（但命名很困难）人们觉得有必要重载“聚合”一词来指代在流中执行事件聚合的事物（即使相关事件集确实代表了状态）聚合体）。
在实现 DDD 书中，功能事件源附录很好地分离了 IIRC - 我倾向于将这个东西（聚合的相关事件的聚合用于制作）称为“折叠状态”（并将这种折叠状态的演变与实际决策分开）
预测（在 DDD-CQRS-ES 用语中）指的是挂在事件上的一组抽象事物，这些事物会针对新事件做出适当的事情（代表人们做出的决定）。投影可以维护一个 非规范化视图 ala 您的“摘要”（不仅有一个）。流具有事件。决策过程将折叠这些事件以推断相关背景以做出决策。 projection 可以具有状态（根据对与流（或其集合）有关的事件的相关子集的有序观察构建）- 它可能是一个保存在键中的 blob-易于查询的值存储。它可能是您通过每次从头开始读取构建的每个流的内存总数。它可能是一个类似的内存缓存，它由某种形式的检查点（最后一次看到的事件）支持，以及一个序列化形式的总结，直到那时。它可以是其中的许多。或者在退化的情况下，你可能还没有连接任何东西。
【讨论】：