在近期于伦敦Skills Matter举行的DDD eXchange 2018会议上，Martin Schimak认为在最近几年间，领域事件引发了越来越多的讨论，但是我们对命令也应如此，在这次会议上他讨论了微服务领域的事件、命令以及长周期的服务，以及流程管理器和类似的工具如何有助于运行核心的业务逻辑。

Schimak是奥地利的一名独立咨询顾问，他认为，事件最好的一点在于，它们代表了已经发生过的事情。我们正在处理越来越多的分布式系统，通过来自服务本身的保证能够让我们更加相信最终一致性。事件还有助于我们解耦服务，并且能够回过头去看过去发生了什么。

事件的优势是事件驱动架构越来越流行的原因之一，有时候，设计只依赖事件就能实现集成服务。有时这种简化是合理的，但是Schimak指出，这也可能会带来一些危险。以简单订单处理为例，在处理过程中，只包含order placed、payment received、goods fetched和goods shipped事件，它们会被支付、存储和运输服务所使用。一个简单的变更，比如在跟客户收费之前就将货物提取出来，就会改变消息流，从而要求所有涉及到的服务都要进行变更，对于Schimak来说，服务之间的这种耦合是一个次优的方案。

因为事件仅仅是已发生的事实，它们本身并不会触发任何的操作。在监听事件的时候，我们需要一定形式的策略，该策略能够决定当特定的事件接收到的时候，应该发生些什么。在纯粹的基于事件的系统中，这种策略始终要位于事件消费服务之中。在基于命令的方式中，这个策略可以位于事件发布服务中，但是Schimak认为，有时候这两个服务都不是合适的选择。对他来讲，第三种方案是新增一个中介者（mediator），它监听特定的事件并决定后续的步骤。

以上面的订单服务为例，这个服务可能会监听相关的事件并发送命令，因此当客户下单时协调流程并完成该订单。在样例中发生这样的变化时，不仅订单服务需要变更。Schimak指出，在这个过程中运行的逻辑通常是属于业务核心领域中的逻辑。

对Schimak而言，命令是一些意图，针对的是未来要发生的事情，他定义了命令执行的两种类型：

• 原子性事务执行，一般的意图是变更一个模型；例如，下单命令会创建一个订单并发布下单事件；

• 复合的、长周期执行，其意图是更加业务级别的结果，可能需要多个步骤才能实现。样例可以是相同的下单命令，但是这里的最终结果是完成订单或取消订单的事件。

在请求支付的场景中，我们应该努力实现有价值的业务结果。支付服务可能会发布payment received或payment cancelled事件。在Schimak的经验中，我们往往会采取相反的措施，暴露一些临时的问题，比如信用卡收费失败，并委托客户端来对其进行处理。这意味着我们要强迫客户端来处理策略方面的问题，而这些问题显然是支付相关的——可能稍后进行重试，有可能使用新的信用卡数据。如果客户端是订单服务的话，那么它不仅要处理订单，还要处理支付，这样就将支付领域的知识扩展到了支付服务之外。这同时也会增加订单服务的规模和复杂性。

将我们的问题委托给客户端并强迫它们处理各种问题，那么它们就变成了上帝服务。

相反，我们应该将支付视为长周期的服务，它要处理支付相关的所有内部问题，并且只发布最终结果相关的事件，即payment received或payment cancelled。Schimak强调，这并不是要创建一个中心化的协调器（coordinator）来处理 整个业务，它指的是更好的API设计，保护不同的限界上下文。

在使用长周期服务时，一个通用的工具是Process Manager。流程管理的常见需求是处理时间和超时、重试以及流程失败时的补偿。我们可以自己实现所有这些功能，但Schimak更喜欢使用Axon消息和Saga管理或Lagom这样的框架。他还建议使用某种形式的业务流程执行引擎，但他强调工具必须是轻量级的，并且可以在单个服务中使用。开源的过程引擎框架包括Activiti、Camunda和Zeebee(也来自Camunda)。在serverless领域，AWS创建了Step Functions，其他云供应商也在朝着这个方向发展。

Schimak个人在长周期服务和业务处理引擎方面的经验包括多年在Zalando的订单处理流程中使用Camunda。他和联合来自Camunda的Bernd Rücker在InfoQ上撰写了两篇文章：事件、流程和长期运行的服务：工作流自动化的现代解决方案和洞悉流程！微服务与事件协同。

原文地址：http://www.infoq.com/cn/news/2018/07/events-commands-services

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com