早在2005年Martin Flower就发表文章讲述了事件溯源的企业应用架构模式(原文), 一开始并没有大规模的流行, 只在一些企业项目中有所应用。 随着时间推移, 人们越来越发现它的优点, 近几年也开始流行起来。

Thought Works的技术雷达更是把它归纳到了试验分类, 可见这个模式已经足够被人们所了解, 可被企业有选择地试用。

事件溯源可确保将所有针对应用程序状态的更改储存为一连串的时间记录。 我们不仅能查询这些事件, 还可以使用事件日志来回溯到过去的状态, 并以此为基础自动调整状态以对这些”更改记录”进行妥善处理。 与业务层面上的事件记录互相参考、补充, 对于那些旨在提供”更宏观客户视野”的业务分析有着积极的影响。

简单的说事件溯源就是把事件作为系统架构中的一等公民来处理, 和领域模型直接交互。 应用系统的状态由一个个事件的发生来产生改变。 事件被作为对象来处理, 业务逻辑就在事件和领域模型的交互中产生。

事件对象有如下特点:

  1. 不可修改性。 事件发生了就发生了, 事件本身是不能被修改和删除的。
  2. 有序性。 事件发生有先后顺序, 顺序不能被改变。
  3. 对偶性。 一个事件可能会与另一个事件表示出相反的逻辑。 比如汽车到达和汽车出发就是一对对偶的事件。

事件溯源模式一般会对事件对象做如下操作:

  1. 持久化。 把事件持久化到数据库或者文件中, 方便日后分析和执行事件相关的重演和回滚操作。
  2. 重演。 让一组事件再发生一次。 比如每日或者每周例行的工作可以用一组事件来表达和执行。
  3. 回滚。 撤销事件对应用系统状态的改变。

如果你在项目中要用到这个模式, 不妨参考下Event Store这个框架。

Event Store是一种开源的函数式数据库, 用于存储不可变事件和对事件流进行复杂的事件处理。

参考文献:

Introducing Event Sourcing