事件溯源中实体切换上下文时的Correlation ID变更处理

系统核心聚合根 #

• Game：代表特定博彩商的体育博彩赛事。
• Combined Game Bucket：基于30分钟开赛时间间隔，将不同博彩商名称相似的游戏分组的容器，每个桶可管理多个合并游戏。

问题描述 #

我需要确保同一事件流内的所有事件共享相同的correlation ID，理想状态是：

• 同一Game事件流内的所有事件共享同一个correlation ID；
• 当Game被合并到Combined Game Bucket时，继承对应合并游戏的correlation ID，确保同一合并游戏下的所有Game共享该ID。

但当Game的开赛时间发生大幅变更（超过30分钟）时，问题出现：Game会从原合并桶中移除并加入新的Combined Game Bucket，但原Game事件流的correlation ID仍指向旧合并桶，而事件溯源中无法修改历史事件的correlation ID，导致后续关联事件无法使用正确的ID。

拟议方案 #

考虑在Game开赛时间大幅变更时创建新事件流，旧流发布GameMovedToNewStream事件指向新流，但这会导致Game的事件历史被拆分到多个流中。

疑问解答 #

1. 在事件溯源中，将Game的事件历史拆分到多个流中是否属于不良实践？ #

这并非绝对的不良实践，但需谨慎使用。事件溯源的常规原则是一个聚合根对应一个事件流，因为聚合根是一致性边界，其事件流代表完整的生命周期。但如果聚合根的核心关联逻辑发生了不可逆的根本性变化（比如这里Game的开赛时间跨了30分钟窗口，导致其所属的合并分组完全变更，相当于业务身份的核心关联彻底改变），拆分流是可接受的，但必须做好以下几点：

• 旧流的GameMovedToNewStream事件必须明确包含新流的ID，确保查询Game完整历史时可以串联所有关联流；
• 应用层需要实现多流查询逻辑，比如封装查询接口，自动遍历Game的所有关联事件流；
• 仅在聚合根的核心业务属性/关联发生不可逆转的重大变更时才拆分，避免频繁拆分导致事件流碎片化。

2. 是否需要重新审视“Game应与所属合并游戏共享同一correlation ID”这一假设？ #

非常有必要重新审视这个假设。Correlation ID的核心作用是追踪同一业务操作链路的事件，而非绑定到某个聚合根的归属关系。原假设混淆了“业务链路追踪”和“聚合归属关联”的概念：

• 如果让Game继承合并桶的correlation ID，本质是把correlation ID当成了“分组标识”，但这并非它的设计初衷；
• 正确的思路是：给Game分配独立的、终身不变的correlation ID，用于追踪其自身生命周期内的所有操作（比如爬取更新、归属变更）；Combined Game Bucket的事件流使用自己的correlation ID；
• 当Game加入/移出合并桶时，通过GameAddedToCombinedBucket、GameRemovedFromCombinedBucket事件记录两者的关联关系，这些事件可以携带合并桶的ID，无需让Game继承合并桶的correlation ID。这样即使Game变更归属，自身的correlation ID保持不变，合并桶的关联通过事件记录即可追踪。

3. 有没有更优方案可在维护Game事件历史一致性的同时，妥善处理此场景下的correlation ID？ #

推荐两种更优雅的方案，无需拆分事件流即可解决问题：

方案一：分离Correlation ID与归属关联

• 给每个Game分配独立的、终身不变的correlation ID，其所有事件都使用这个ID；
• Combined Game Bucket的事件流使用自身的correlation ID；
• 当Game加入/移出合并桶时，发布GameAssociatedWithCombinedBucket或GameDisassociatedFromCombinedBucket事件，事件中包含合并桶ID和Game的correlation ID，以此建立两者的关联；
• 若需要查询同一合并桶下的所有Game事件，通过事件存储的查询能力（比如按合并桶ID过滤关联事件，再关联对应的Game事件流）即可实现，无需共享correlation ID。

方案二：使用归属变更事件维护关联

• 保留Game的单一事件流，当开赛时间变更导致归属变更时，发布GameCombinationBucketChanged事件，事件中包含旧桶ID、新桶ID；
• Game的correlation ID始终绑定自身，无需变更；
• 在读取模型（Projection）中维护Game与合并桶的实时关联关系，当处理到GameCombinationBucketChanged事件时，更新读取模型中的归属信息，后续查询合并桶下的Game时直接从读取模型获取，无需修改历史事件。

内容的提问来源于stack exchange，提问作者Ari Seyhun