北京
全球7000种编程项目里，能真正玩转事件溯源（Event Sourcing）的不到十分之一。这不是技术门槛问题，是很多人根本没搞懂：为什么要把数据库变成一本"只追加不修改"的流水账？
Nebuild GmbH创始人Martin Dilger最近在SE Radio的访谈里，把这件事讲透了。他和主持人Giovanni Asproni聊了一个小时，核心就一句话：别只存"现在是什么样"，要存"怎么变成这样的"。
先厘清几个容易混的概念。事件溯源（Event Sourcing）是架构模式，事件建模（Event Modeling）是设计方法，事件流（Event Streaming）是传输机制，事件风暴（Event Storming）是协作工作坊。四者相关但各司其职。Dilger特别强调，事件建模是入门事件溯源的最佳路径——先画明白业务流程里的时间线，再谈技术实现。
这种架构的核心操作只有三个：读事件流、追加新事件、通过投影（Projection）生成当前状态。没有UPDATE，没有DELETE，只有INSERT。听起来反直觉，但Dilger解释了两个关键优势：审计追踪天然完整，任何时间点的系统状态都能重建；业务语义直接映射到代码，不用在对象关系映射（ORM）里绕弯子。
代价同样明显。存储膨胀是头号问题——七年前的用户改名记录可能永远躺在库里。查询性能也需要额外设计，因为不能直接读"当前余额"，得把所有存取事件重放一遍。Dilger的建议很务实：事件溯源不是银弹，适合领域模型复杂、审计要求严格、或者需要时间旅行调试的场景。简单的CRUD应用，传统方式更高效。
对于存量系统改造，Dilger给出了一条渐进路线。不必推倒重来，可以在边界上下文（Bounded Context）里试点，用防腐层（Anti-Corruption Layer）对接旧模块。新书《Understanding Eventsourcing》和《Real World Event Sourcing》里收录了更多实战案例，包括如何处理并发冲突、如何设计 Saga 长事务、以及垂直切片架构（Vertical Slice Architecture）与事件溯源的配合。
访谈最后聊到社区资源。除了Martin自己的播客，Event Modeling官网提供交互式教程，Apache Kafka作为事件流平台被频繁提及，而领域驱动设计（DDD）和整洁架构（Clean Architecture）的相关著作则是理解底层设计哲学的基础。Dilger的结论是：事件溯源最难的不是技术，是改变"状态即真相"的思维惯性。一旦跨过这道坎，系统会自己讲故事。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
