事件溯源模式下存储状态事件是否可行？包裹运输场景探讨

你的第二种方案完全可行，而且在很多实际场景中是更合理的选择，并没有违背事件溯源的核心原则。

为什么状态派生事件不违反事件溯源原则？ #

事件溯源的核心是记录导致状态变化的操作事实，但这并不意味着不能记录派生的状态事件——关键在于这些派生事件是基于操作事件的确定性计算结果，而非凭空生成的状态快照。只要派生事件的生成逻辑是纯函数式的（即给定相同的操作事件序列，总能得到相同的派生事件），就不会破坏事件溯源的可重放性和一致性。

方案2的核心优势 #

• 避免读写端逻辑耦合：无需在聚合根和读模型之间共享状态计算代码，减少了维护成本，尤其是当状态依赖多层派生时，共享逻辑会变得复杂且容易出错。
• 读模型性能优化：读模型可以直接消费Itinerary updated事件，无需重放所有操作事件来计算行程状态，大幅提升查询效率，特别是对于频繁查询的场景。
• 清晰的事件语义：派生事件明确标识了行程状态的变化点，让事件日志更具可读性，便于后续的调试和分析。

需要注意的关键细节 #

• 确保派生逻辑的确定性：生成Itinerary updated事件的逻辑必须是纯函数，不能依赖外部状态或随机因素，保证重放操作事件时能生成完全一致的派生事件。
• 避免冗余数据：派生事件只需包含行程的必要信息，无需重复操作事件中已有的数据，防止事件日志过度膨胀。
• 事件顺序一致性：派生事件必须紧跟在触发它的操作事件之后写入日志，确保读模型消费时能按正确顺序更新状态。

总结 #

生成派生的状态事件是事件溯源架构中常见的优化手段，它平衡了写端的逻辑清晰性和读端的查询性能，完全符合事件溯源的核心思想——只要所有状态变化都能通过事件日志重放得到一致结果，就没有问题。

内容的提问来源于stack exchange，提问作者Simon Watiau