场景
已经应用了Saga模式，为了可靠性，每当服务状态改变时，服务必须以原子性方式发布事件。使用一个跨数据库和消息代理的分布式事务是不切实可行的。
问题
每当状态改变的时候，如何可靠地/原子地发布事件？
约束条件
2PC不是一个选项。
解决方案
这个问题一个好的的解决方案是使用事件溯源。事件溯源持久化某个业务实体的状态，比如某个订单或某个用户，作为一系列状态改变事件。每当某个业务实体状态改变时，一个新的事件会被附加到事件列表。因为保存一个事件是单点操作，它是内在的原子性的。应用通过重放事件来重建某个实体的当前状态。
应用持久化事件到某个事件仓库中，事件仓库是一个事件数据库。该仓库有一个API来增加和查找一个实体事件。该事件仓库行为也想一个消息代理。它提供一个API使服务去订阅事件。当某个服务保存一个事件到事件仓库时，事件会被投递到所有感兴趣的订阅者那里。
某些实体，比如一个用户，能够有大量的事件。为了优化负载，应用可以周期性地保存某个实体当前状态的快照。为了重建当前状态，应用查找最新的快照和发生在该快照后的事件。因此，只有很少的事件被重放。
实例
用户和订单是使用事件溯源和CQRS的一个实例应用。该应用使用Java编写和Spring Boot。使用Eventuate构建，Eventuate是个基于事件溯源和CQRS的应用平台。
下图展示了如何持久化订单的：
应用持久化每个订单作为一系列事件，而不是简单地存储每个订单当前状态到订单表（ORDERS）的某一行。用户服务（CustomerService）能够订阅订单事件并且更新自己的状态。
下面是订单的聚合：
下面是一个在订阅订单事件的用户服务里面的事件处理器的例子：
通过尝试为订单用户预留信用额度来处理某个订单创建（OrderCreated）事件。
影响
事件溯源的优点：
解决了在实现事件驱动架构中的一个关键问题，使得每当状态改变时，可靠发布事件成为可能。
因为持久化的是事件而不是领域对象，最大限度的避免了对象关系抗阻不匹配的问题（object‑relational impedance mismatch problem）。
提供了100%可靠的业务实体改变的审计日志。
使得实现基于时间的实时查询来确定任何时间点的某个实体状态成为可能。
基于事件溯源的业务逻辑由松耦合的互相交换事件的业务实体组成。这使得迁移单体应用到微服务架构很容易。
事件溯源的弊端：
事件溯源是一种不同的和陌生的编程风格，因此存在学习曲线。
由于它需要标准的查询来重建业务实体的状态，事件仓库查询起来很困难。这很可能变得很复杂和效率低下。因此，应用必须使用CQRS来实现查询。相应地这意味着应用必须处理数据的最终一致性问题。
