事件溯源:处理派生数据

Question

事件溯源系统如何处理派生数据？我读过的关于事件溯源的所有例子都展示了对事实事件使用react的服务。一个流行的例子似乎是:

银行账户系统

事件

存入资金

提取资金

服务

平衡服务

然后他们展示了 Balance 服务如何在任何时候从事件中导出状态(即余额)。那讲得通;这些事件是事实。毫无疑问，它们发生了——它们在系统之外。

但是，我们如何处理系统计算出来的数据呢？

例如。

overdraw 服务:

负责监控余额并在余额低于零时执行某些操作的服务。

事件溯源方法是否规定了我们应该如何使用(或不使用)派生数据？ IE。余额。也许是以下之一？

1) 用途:【资金提取事件】+【余额服务查询】

监听“资金提取”事件，然后向 Balance 服务询问当前余额。

2) 使用:[余额改变事件]

获取余额服务以抛出包含当前余额的“余额已更改”事件。据推测，这不是“事实”，因为它不是系统外部的，因此容易计算错误。

3) 用途:【资金提取事件】+【资金存入事件】

我们可以跳过 Balance 服务，让每个服务直接根据事实维护自己的平衡。 ...虽然这会导致每个服务都有自己的(可能不同的)平衡版本。

Answer 1

事件溯源是一门不断发展的学科，有许多不同的实践、从业者和有魅力的人。您不能指望他们为您描述的所有场景提供一些非常一致的建模技术。这些场景中的每一种都有其优点和缺点，您指定了其中的一些。此外，一个项目与另一个项目之间的差异可能很大，因为业务需求(市场的演变压力)会有所不同。

如果您正在处理一些关键任务系统并且希望始终保持非常一致的平衡 - 最好使用 RDBMS 和 ACID 事务。

如果您需要最大速度，并且您对最终一致的状态没问题，并且不太担心余额的精度(由于各种原因，某些事件可能会在这里和那里丢失)，那么您可以异步地从事件中推导出余额的预测。

在这两种情况下，您都可以使用事件溯源，但不一定非要异步生成投影。如果您确实需要这样做，则可以在更改写入模型时在同一事务范围内生成投影。

它会让 Greg Young 开心吗？我不知道，但如果有一天你的余额在关键任务系统中不同步，谁会关心这些事情......