基于事件系统中的过程管理器

DDD 架构&设计

摘要： Bernd Rücker在今年的DDD eXchange大会上演讲中提出，以发布事件的方式去通知领域内的更改，可实现不同领域彼此分离。但是如果逻辑事件流的确存在，事情就变得不明显了，并难以领会了。更好的解决方案是使用过程管理器（Process Manager）对全过程进行追踪。

作者： Jan Stenberg

正文：

以发布事件的方式去通知领域内的更改，可实现不同领域彼此分离。但是如果逻辑事件流的确存在，事情就变得不明显了，并难以领会了。更好的解决方案是使用过程管理器（Process Manager）对全过程进行追踪。这是Bernd Rücker在今年的DDD eXchange大会上演讲中提出的，演讲的内容涉及长期运行过程和领域驱动设计（DDD，Domain-Driven Design）。

Rücker在长期运行过程上具有十多年的工作经验，他也是Camunda的联合创始人。在他看来，网购的过程从用户的角度看是十分简单的，就是下单、支付和快递。从DDD角度看，实现网购可能需要四种业务能力及相应的受限上下文，包括商店、支付、盘存和快递。这些上下文进而生成了匹配网购过程的领域事件，即下订单、收到付款、货物分拣和商品快递。

为完成下订单过程，上下文需要协作并响应所提交事件。当一个下单事件提交后，订阅此事件的支付上下文将在会在完成支付事件提交前，收到订单的支付款。一个问题是，支付上下文需要知道订单的支付时间，以及所以可触发支付的事件。实际上，这就意味着一旦新客户需要支付，必须要访问支付上下文。

Rücker指出，虽然事件流导致了低耦合，但是其中并没有过程这一概念。这是事件流的一个问题，导致整个逻辑流非常难以看到，就此问题他提及了Martin Fowler的一篇文章。另一个问题是，导致事件流发生更改的新业务需求（例如VIP客户可以要求带发票的订单），可能需要更改多个上下文。

Rücker提出了一种更好的解决方案，即使用过程管理器在一个地点上跟踪整个过程。其中过程管理器的主要职责是：

• 事件到命令的转化。下单事件是已经发生的事件，隐含了我们的确希望发生的一些事情、一个命令等。在本例中，这可以是读取支付命令。
• 以领域逻辑一等公民实现事件流。事件流的整体以及每个独立步骤中的逻辑，是所涉及的上下文中的领域逻辑的组成部分。
• 为长期运行流处理状态。

在Bücker看来，状态处理是实现中最具挑战的事情。其实现方法包括：

• Actor模型，其中actor持有本地状态，模型可使用Akka等。一个actor用于实现过程管理器，对整体流负责。这一方法在Vaughn Vernon所著的《Reactive Messaging Patterns with the Actor Model》一书中也做了介绍。

• 在实体中保持过程流的状态。就Rücker的经验而言，这是一种十分常见的实现方法。

• 程单模式（Routing Slip）。其中所需的所有步骤一并通过消息发生，避免了集中存储过程状态的需要。

• 定义了各个步骤的状态机。Rücker指出，对过程状态的可见性是使用状态机一个优点。

在与实现长期运行过程的客户的工作经验中，Rücker接触到了一些常犯的错误，其中包括使用无工作流或是自研发的引擎，以及使用无代码套件。为此，他推荐使用一些可嵌入到用户代码中的开源轻量级框架库，Camunda是其中之一。他还建议仅去实现那些通用的用例，剔除一些十分异常的用例。这可能会关照到99%的用例，剩余的留给人工干预。这一做法也得到了Greg Young的推荐。

Rücker在GitHub上发布了一个例子。该例子使用在演讲中给出的方法实现了一个基本的订单系统。

明年的DDD eXchange大会计划于2018年4月26日至27日期间在伦敦召开。

查看英文原文： Process Managers in Event-Based Systems