Explains event sourcing in one…

# Event Sourcing 一句话讲透

一句话：Event Sourcing 不存“当前状态”，而是把每一次状态变更作为不可变事件持久化下来，当前状态由重放事件得出——就像银行不存“余额”，而是存每一笔流水，余额是算出来的。

电商库存扣减场景对比

传统方式（存状态）

• 表里就一列 stock = 87
• 扣减时 UPDATE stock = stock - 1
• 问题：谁扣的？什么时候扣的？为什么是 87？——全丢了

Event Sourcing 方式（存事件）

• 事件表追加写入（append-only）：
• StockInitialized(productId=P1, qty=100)
• StockDeducted(orderId=O1, qty=5)
• StockDeducted(orderId=O2, qty=8)
• 当前库存 = 事件流重放聚合的结果（100 - 5 - 8 = 87）

Java 后端落地的核心组件

• 聚合根：StockAggregate，只提供 deduct() 方法，内部校验“库存是否足够”，通过则产生事件
• 事件存储：追加写 event_store 表（或用 Axon Framework、Kafka 做事件流）
• Projection（读模型）：异步消费事件，物化出 stock 查询表，避免每次重放全部事件
• 乐观锁：用聚合的版本号（expected version）防止并发扣减冲突，天然解决超卖问题

核心收益与代价

收益

• 完整审计：每个订单扣了几件、何时扣的，可追溯
• 天然解决并发：事件是串行追加的，不会出现“两个请求同时读到 87”的经典超卖 bug
• 可回溯：StockReturned（退货回补）加进去就行，历史随时可重算

代价

• 查询必须配合读模型（CQRS），不能直接查聚合
• 事件结构变更需做版本升级（upcasting）
• 学习成本和最终一致性复杂度不低

一句话总结：库存不是被“改”出来的，是被一串扣减事件“累”出来的。