转载

将整个系统建立在事件溯源上是一种反模式

在今年早些时候所举办的领域驱动设计欧洲大会上， Greg Young 进行了一场演讲。他在演讲中表示，命令查询职责分离模式（CQRS）从来都不是我们所致力于实现的终极目标，它只是带领我们迈向事件溯源（Event Sourcing）模式这一终点的阶梯。不过，他同时也认为，即使我们仅仅采纳了CQRS模式，将应用的读写进行分离，而仍然使用同一个数据库，这也同样是一种有价值的模式。他曾见过许多团队以这种方式构建系统。

Young回顾了事件溯源模式在这10年来的发展，他看到这一模式已在许多新领域中实现了突破，而不仅仅限于具有大量事务写入操作的传统领域，例如金融与博彩领域。对事件的建模促使开发者更为关注软件的行为，而不是其结构，这种方式在和习惯与传统软件打交道的领域专家进行交流时将体现出更为明显的作用。此外，对事件的建模也促使开发者更关注于瞬时的状况，在这种系统中，时间就成为了一个至关重要的因素。对于各事件随着时间流逝而产生的相互关联的思考，往往会使我们了解核心的领域知识。

在过去几年中，事件风暴（Event Storming）这种形式获得了极大的成功。对此，Young表示对事件的建模并不只这一种形式，他提到了 Alberto Brandolini 所介绍的一种形式，即以一种探索式的方式找到领域中的问题。Young本人也会使用另一种形式，只关注于某一个流程，这种形式的目的在于发现服务的边界。他期望事件风暴过程未来能够变得更为正规化，并鼓励听众多加以关注。

而Young在过去10年间所见到的最糟糕的做法，就是将整个系统建立在事件溯源模式之上这种常见的反模式。这是一种严重的错误，会造成一个基于事件溯源模式的整块应用。CQRS与事件溯源都不是顶层的架构，应当有选择性地在少部分场景中使用。

Young所提到的最后一个问题是流程管理器（Process Manager）的缺失。如果所构建的系统中的大量服务直接订阅由其他服务所生成的事件，会使开发者难以理解系统的实际工作方式。除非能够逐个翻阅每个服务中的代码，否则将很难发现整个流程的真实面貌。Young指出，虽然流程管理器的设计并不容易，但他相信其原理已经在《企业整合模式》（Enterprise Integration Patterns）这本书中得到了最好的解释。

Young也对未来进行了一番展望，他相信会出现更多通过函数式编程进行事件溯源开发的情形。他表示，虽然事件溯源模式往往与面向对象思想相结合，但它却是一种纯粹的函数式模式，因此非常适合于用函数式代码进行表达。在他看来，将有越来越多的事件溯源系统基于函数式代码进行开发。

Young同时也相信流程管理器的使用将变得更为普及，而 Actor （角色）模型越来越广泛的应用也将对此起到积极的推动作用，因为在Young看来，Actor就是实现流程管理器的完美选择。他甚至将Actor框架描述为一种流程管理器框架。

明年的领域驱动设计欧洲大会预计将在2017年1月底举办。

查看英文原文： Event Sourced Systems is an Anti-Pattern

原文 http://www.infoq.com/cn/news/2016/05/event-sourcing-anti-pattern

正文到此结束