DDD

Event Sourcing explained - part 1

事件源模式使用追加记录的方式来记录发生在一个领域中针对数据的操作，而不是仅仅只存储当前的状态，所以能够物化领域对象。通过这种方式能够简化一些需要同步数据模型和业务领域的复杂领域，能够提高性能，可扩展性以及响应性,保证事务型数据的一致性，对需要提供补偿操作的动作提供完整的记录。

大部分的应用都是需要和数据进行交互的，通常的做法是当用户操作数据时维护数据的当前的状态。例如在传统的CRUD模型中，一个典型的数据操作流程是从存储中读取数据，修改数据，存储修改后的状态-通常使用事务来锁住数据。

但是CRUD模型有一定的限制：

  • CRUD系统中执行更新操作时可能会影响性能和响应性，由于操作需要的额外的开销也限制了可扩展性。
  • 在一个需要和众多的并发用户交互的领域模型中，由于数据的更新发生在单一的数据记录上，因此更容易发生冲突。
  • 除非有额外的审计机制来记录每一个操作，否则历史数据将会丢失。

使用事件源机制的最重要的好处就是它内建了审计机制来保证交易数据和审计数据的一致性，因为二者是同样的数据。通过事件来展示数据使得能够及时的在任何时间重建任何对象的状态。

下面是使用事件源机制带来的额外的好处。

  • 性能。因为事件是不可变的，所以当你保存事件的时候可以使用追加的方式。事件同时也是简单的、单一的对象。相比较使用复杂的关系模型，所有的这些因素能够促成更好的性能和可扩展性。
  • 简单。事件是描述系统中发生了什么的简单对象。通过只存储事件能够避免存储福大领域对象到关系型数据库中所带来的复杂性。
  • 审计跟踪。事件是不可变的，并且存储了系统中状态的所有的历史记录，所以能够系统中发生了什么的完整的详细的记录。
  • 和其它的子系统集成。事件提供了同其它子系统进行交互的方便的方式。事件能够向其它对系统状态变迁感兴趣的子系统发布事件, 同时记录这些发事件。
  • 从事件历史中得到额外的业务数据。通过存储事件，你就可以通过查询相应的事件来得到系统在这之前的任意一个时刻的状态。如果你存储了事件，你将不会丢弃将来可能会有用的数据。
  • 生产环境故障诊断。 你可以通过拷贝一份生产系统中的事件记录并且在测试环境中重放来诊断生产环境中的故障。如果你知道生产环境中产生故障的时间，那么你将能够通过事件重放很容易的观察到系统中究竟发生了什么。
  • 修复错误。 你可能发现造成计算数据不准确的编码错误。你可以通过修复代码并且重放事件流而不是通过人工冒险修复已经存在的数据。
  • 测试。聚合中的所有的状态的变迁都会被存储为事件，因此可以很容易的测试聚合中的一条命令是否符合期望。

事件溯源并不是一个顶层的架构，它应该被应用于正确的地方，例如交易系统等。如果一整个系统都应用事件溯源，就变成了反模式。

参考文献