体验构建反应式事件驱动的 CQRS 应用

Duncan DeVore 在一次近期的演讲中谈到，设计一个不变的领域模型并与之进行反应式（Reactive）编程对我们的新架构而言是非常重要的需求，Duncan 在演讲中还对他构建分布式应用的体验进行了分享。该分布式应用基于 CQRS 、最终一致性 和 事件溯源（ event sourcing ），并且是采用 Akka 和 Scala 编写的，

Duncan 是一家能源公司的工程副总裁，他对 Command Query Responsibility Separation (CQRS，即命令查询职责分离) 进行了描述：将命令与查询分离到两个对象中，使它们在其他方面可以进行单独的优化，根据 Duncan 的经验，这是一种非常常见的需求。对于命令（Commands）而言，虽然它们会改变状态，但是它们并不涉及数据的编辑，它们只是行为，是一个对执行某个任务或某个动作的请求，它们更适合作为一条消息进行传递。而查询（Queries）则是位于数据存储之上的一层很轻薄的读取层，它并不是领域的映射，相反，数据通常是基于抓取（fetch）和页面结构（screen structure）存储的，并且拥有一个可以读取所有需要数据的键。将写和读分离的一个重要挑战是最终一致性，它会使得在写发生一段时间后，读取才可能展示出相同的数据。

当今大多数的业务应用都依赖对当前状态的存储，而 Duncan 认为这是由于采用了关系型数据库系统（ RDBMS ）的副作用。相比而言，事件溯源是针对事件的捕获，这是一种贴合自然的行为，它不会保持当前的状态，它保持的是状态的根源。我们来讲一个可以阐述这种方式优势的例子，有一个这样的需求，我们需要现有的购物车能够报告所有用户在购物车（取出商品后）所产生的订单。如果一个系统只是跟踪当前的状态，那么它只能报告新的订单，而对于基于事件的系统，所有订单的事件都保留在系统里，唯一需要做的就是向系统添加报告这项功能。

在成熟的业务模型中，行为跟踪的概念很常见。举一个例子，在一个银行账户中，每一比交易事务，比如存款和提款都会被记录下来。我们之所以信任当前的状态是因为该状态可以通过重放所有前面的交易事务来重新创建，而且该状态也可以通过对账来确认有效性。

Duncan 强调了与事件打交道的两个技术性影响，第一个是存储系统成为了一种只有追加操作（译者注：即没有更新）的架构，这种架构更加容易分发，第二个是水平分区变得更加容易，因为抓取数据时使用的只是一个单独的键。

Duncan 最后引用了他自己的一段话进行了总结：

我相信将 CQRS 和事件溯源结合可以为构建遵循反应式宣言（ Reactive Manifesto ）的分布式应用提供一种清晰且简明的方式。

反应式宣言（ Reactive Manifesto ）于 2013 年九月发布，目前已经有 6,300 人签署了该宣言。

Duncan 是一本即将出版的名为《构建反应式应用》（“Building Reactive Applications”）的图书的联合作者。

查看英文原文： Experiences Building a Reactive Event-Driven CQRS Application