PS：原创文章，如需转载，请注明出处，谢谢！
前几天团队内做了DDD如何有效指导拆分微服务的分享，中间关于微服务集成提到了“事件溯源”，今天就此做下整理。
1、关于事件溯源
事件溯源由DDD理论提出的。
在不同的界限上下文中，共享成员的含义、用法以及他们的对象属性都会有些不同，DDD建议这些共享成员在各自的界限上下文中都分别建自己的类（包括数据库表），而不是共享。可以通过数据同步的手段来保持数据的一致性。
2、事件溯源是什么？
事件溯源是微服务的一种存储方式，它是微服务的内部实现细节。
通常整个应用程序只有一个Event Store， 不同的微服务都通过向Event Store发送和接受消息而互相通信。
Event Store内部可以分成不同的stream（相当于消息队列中的Topic）， 供不同的微服务中的领域实体（Domain Entity）使用。
3、事件溯源与传统数据库存储
数据库存储方式只能保存当前状态，而事件溯源则存储了所有的历史状态，因而能根据需要回放到历史上任何一点的状态，具有很大优势。
由此带来的问题主要包括：
1）程序比较复杂，因为事件是一等公民，你必须把业务逻辑按照事件的方式整理出来，然后用事件来驱动程序。
2）如果你要想修改事件或事件的格式就比较麻烦，因为旧的事件已经存储在Event Store里了（事件就像日志，是只读的），没有办法再改。
4、事件溯源与事件通知
两者表面上看起来很像。
事件通知只是微服务的集成方式，程序内部是不使用事件溯源的，内部实现仍然是传统的数据库方式。只有当要与其他微服务集成时才会发消息。而在事件溯源中，事件是一等公民，可以不要数据库，全部数据都是按照事件的方式存储的。
5、事件溯源的落地
常用于记账和源代码库变更记录，区块链也是其重点应用场景。