事件溯源中的聚合到底是什么？

Question

我真的很喜欢事件溯源的概念。回放特定事件来计算领域模型状态真是太棒了。

当我阅读事件溯源时，我仍然对“聚合”一词感到困惑。我将聚合理解为“与特定事物相关的事件集合”。

与此不同的是，“Projection”是一种事件处理程序，在触发事件（由 Projector 支持）时调用。当重放事件流时，投影仪可能会（再次）处理此事件。

事件处理程序（Projector）可以对事件作出反应。例如，有一个 ERP 应用程序，员工可以在其中运送、预订或发布产品。如果产品已发货，则会触发一个名为 ProductShipped 的新事件（并保存到数据库中）。充当事件处理程序的投影仪到位并减少该产品的可用库存数量。

如果我没看错的话，聚合可以充当验证器。因此，如果我查看与该产品相关的所有过去事件，我就能够计算出数量。这个计算必须在 ProductShipped 事件被持久化之前完成，这就是聚合的作用。

如果我是对的，聚合器何时出现？获取有关可用数量的信息。但这似乎很奇怪，因为投影机必须重播所有事件（与 SKU 相关）才能获取此信息。此外，这似乎违反了关注点分离原则。

在一些教程中，我发现聚合本身就是“控制源”：如果员工运送产品，应用程序将调用方法 ProductStockAggregate.shipProduct(productId)。此方法将重播与该产品相关的所有过去事件，并确定该产品是否可发货（基于数量可用性）。该决定会导致一个新事件（ProductShipped 或 ProductQuantityTooLow），该事件必须由应用程序处理。但如果这是真的，那么也会违反关注点分离，因为聚合必须知道必须触发的事件、产品模型本身以及执行业务规则的逻辑。看起来像神物。

但我倾向于认为我并没有真正理解特别的东西。你能帮帮我吗？

Answer 1

当我阅读事件溯源时，我仍然对“聚合”一词感到困惑。我将聚合理解为“与特定事物相关的事件集合”。

事件溯源中的“聚合”与域驱动设计中的“聚合”含义相同。

这是在“蓝皮书”（Domain Driven Design: Tackling Complexity at the Heart of Software -- Eric Evans，2003 年）中确定的模式；更具体地说，它是一种生命周期管理模式（第 6 章）。

AGGREGATE 是一组关联对象，我们将其视为一个单元以进行数据更改。

我们在这里真正谈论的是域模型中的对象；主要是管理我们域中信息更改的实体，但当然我们也会在此处包括为这些实体保存值的对象。

在学习事件溯源时，回顾 Evans 是一个非常好的主意[tm]，因为大部分谈论（和做）事件溯源的人都是通过 DDD 的血统来接触它的。

---

“事件的收集”不太正确，但考虑到事物的历史和可用的文献，这是一个可以理解的混淆。

事件溯源是关于使用事件历史作为我们的数据模型（特别是使用事件历史作为域中信息的持久表示）。

事情纠结的地方是“视为一个整体”位；将聚合视为一个单元会为我们加载和存储聚合数据的方式增加一些限制 - 特别是，我们需要确保对该数据的更改是原子的（所有更改都已保存或不保存更改）。如果您的存储设备是一个“事件存储”，一次只允许您保存一个事件流（历史），那么将“聚合”和“流”对齐就变得很自然了。