事件采购系统如何处理派生数据？我在事件采购中阅读的所有示例都表明服务对事实事件的反应.一个流行的例子似乎是:
银行账户系统
活动
服务
然后,他们将展示Balance服务如何在任何时候从事件中获得状态(即余额).那讲得通; 那些事件都是事实.毫无疑问,他们发生了 - 他们是系统外部的.
但是,我们如何处理系统计算的数据？
例如
透支服务:
一种服务,负责监控余额并在低于零时执行某些操作.
事件采购方法是否决定了我们应该如何使用(或不使用)派生数据？即平衡.也许下列之一？
1)使用:[资金撤回事件] + [余额服务查询]
听取"资金撤销"事件,然后向Balance服务询问当前余额.
2)使用:[余额变更事件]
获取余额服务以抛出包含当前余额的"余额已更改"事件.据推测,这不是一个"事实",因为它不是系统的外部因素,因此容易计算错误.
3)使用:[资金撤销事件] + [资金存入事件]
我们可以跳过Balance服务,让每个服务直接从事实中保持自己的平衡.......虽然这会导致每个服务都有自己的(可能不同的)余额版本.
事件溯源是一门不断发展的学科，拥有众多不同的实践、从业者和有魅力的人。您不能指望他们为您所描述的所有场景提供一些非常一致的建模技术。这些场景中的每一种都有其优点和缺点，您指定了其中的一些。此外，由于业务需求（市场的演进压力）不同，一个项目与另一个项目之间可能会有很大差异。
如果您正在开发一些关键任务系统，并且希望始终保持非常一致的平衡 - 最好使用 RDBMS 和 ACID 事务。
如果您需要最大速度，并且您对最终一致的状态感到满意，并且不太担心余额的精度（由于多种原因，某些事件可能会在这里或那里丢失），那么您可以从事件异步导出余额的预测。
在这两种情况下，您都可以使用事件源，但不一定必须异步生成投影。如果您确实需要这样做，可以在更改写入模型时在同一事务范围内生成投影。
这会让格雷格·杨高兴吗？我不知道，但如果有一天你的余额可能在关键任务系统中不同步，谁会关心这些事情......
| 归档时间： |
|
| 查看次数： |
682 次 |
| 最近记录： |