Event Sourcing架构中是否需要单独建表存储对象的最新状态？

两种模式均为行业通用实践，没有绝对的优劣，需要结合业务场景选择：

方案1：每次从事件存储重建实体 #

• 适用场景：对审计溯源要求极高、单实体生命周期内事件总量少、写操作远多于读操作的场景，比如金融核心交易、司法存证、供应链溯源类系统
• 实现逻辑：接收修改命令后，拉取该实体对应的所有历史事件，逐遍回放生成实体的最新状态，完成业务校验和修改后，将新产生的事件写入事件存储即可，不需要额外维护状态表
• 优势：不存在多数据源一致性问题，所有变更完全以事件为准，不需要额外开发状态同步逻辑，开发维护成本低
• 劣势：如果单实体对应的事件量很大（比如单用户累计有上万条行为事件），每次回放重建的耗时会大幅上升，读性能会成为明显瓶颈

方案2：同时维护事件存储与最新状态表 #

这是目前中大型业务系统中更常用的落地方式，通常和CQRS架构搭配使用：

• 实现逻辑：写路径仍然遵循事件溯源规范，接收修改命令后可以选择从事件存储重建实体，或者直接读取最新状态表完成校验和修改，写入新事件后，通过同步/异步订阅的方式更新最新状态表；读请求直接访问状态表返回结果，不需要回放事件
• 适用场景：读操作占比高、对查询性能要求高、单实体事件量大的普通业务系统
• 优势：读性能极高，支持复杂的多维度查询，适配绝大多数普通业务的性能要求
• 注意点：需要处理事件和状态表的一致性问题，如果采用异步同步的方案，需要容忍毫秒到秒级的最终一致性；如果要求强一致性，可以在写入事件的同时同步更新状态表，或者给状态表增加版本号字段，和事件的版本号做校验避免并发冲突

通用优化方案 #

如果选择纯事件溯源方案但存在重建性能问题，可以增加快照机制：每累计N条事件就存储一份当前实体的快照数据，后续重建时只需要读取最新快照，再回放快照生成之后的事件即可，不需要从第一条事件开始回放，能大幅降低重建耗时。

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