使用DDD、事件风暴和Actor来设计反应式系统

领域驱动设计（domain-driven design，DDD）通常在微服务领域用于查找边界（限界上下文）。同样来自DDD的聚合（aggregate）对于定义持久化和一致性的范围来讲也是很重要的。 但是，并不是领域驱动设计中的所有内容都适合微服务，Lutz Huehnken在柏林举办的microxchg 2018的演讲中讨论了如何使用DDD、事件风暴（Event Storming）和基于Akka的Lagom框架来构建反应式系统，在这个过程中模型与实现会按照1-1的方式进行映射。

在DDD中，传统上会关注系统的静态结构，当我们与领域专家交流的时候会聆听他们的名词。Huehnken是一位独立咨询顾问，对他来讲关注静态属性通常会导致糟糕的边界。因此，他主张我们应该关注动态性和事件。在设计的初期阶段，至关重要的并不是事物，而是所发生的事情。

事件风暴

事件风暴主要是来自DDD社区的一个工作坊，用于快速探索复杂的业务领域。在这个过程中，会使用一面大墙作为建模面，并使用贴纸来代表模型。我们将业务人员和开发人员聚集起来，并采用事件的方式查找领域中所发生的事情。当找到事件时，会尝试沿着一个时间线对它们进行排序。随后，我们会添加触发每个事件的命令。Huehnken在这里没有基于实体看上去的从属关系创建聚合，而是希望能够根据命令流和事件而生成聚合。这会给聚合带来不同的视角，它会对命令和事件一起进行逻辑分组，他相信这种方式能够为我们带来更好的边界划分，并且有助于将聚合分割到不同的服务中。

在Huehnken的经验中，事件风暴是一个强大的工具，在一些较大规模的场景中更是如此，但是它可以用于不同的级别。他发现我们还可以将其用到一个更加技术化的级别，用于建模服务和聚合。这种方式的一个巨大优势就是能够将模型和实现匹配起来，这在DDD中是非常重要的。

反应式系统

反应式系统指的是构建具备即时响应性、弹性、适应性以及消息驱动特征的系统。实现这些特征的方式是异步消息。对于Huehnken来说，微服务的关键点在于隔离、快速反应并且能够在部署新版本服务时不影响系统的其他组成部分，所以对他来说，这两个概念非常具有互补性，我们需要反应式的微服务。

实现反应式系统的教科书式技术是Actor，但是Huehnken认为这种模型并不像他想象中的那样被广泛采用，他相信造成这一点的原因在于从单体模型进行转移所需的思想方式转变。在单体模型中，我们可以访问任何的内容，甚至可以跨越已存的逻辑边界。在真正的分布式系统中，会具有网络边界，我们无法以整体的方式访问系统。涉及到多个聚合的业务进程可能会需要像sagas这样的模式。现在，我们还要告别全局状态，在分布式系统中，每个服务是本地化的，已经过去的事情要通过事件来表示。

Huehnken认为我们已经有了一个非常有趣的采用Actor的实现技术。现在有多个可用的框架，包括Erlang和Akka。Lagom是一个更新、更具倾向性的微服务框架，它基于Akka、CQRS和事件溯源（event sourcing）。因为思维方式的挑战，人们在构建复杂异步解耦的系统时还较为困难，但是如果我们想要将建模技术和实现技术结合起来，这将是一个非常好的机会。

在DDD中，非常重要的一点在于代码要表述模型的概念。Huehnken认为我们在这一点上已经迷失并且在偏离方向。我们已经开发了实现技术，并且又独立开发了新的建模技术，现在我们必须将它们结合起来，这样来自模型的理念能够直接反射到代码中，这样的话，会在构建分布式系统方面取得真正的突破。

会议演讲的视频进行了录制，其中有一部分已经发布，更多的视频稍后会发布。

相关文章：

• Actor-ES框架：Ray

• Actor-ES框架：Ray--事件（Event）编写说明

• Ray框架Q&A

• Actor-ES框架：Ray-Handler之CoreHandler编写

• Actor-ES框架：Ray-Handler之ToReadHandler编写
  

原文地址:http://www.infoq.com/cn/news/2018/04/reactive-actors-eventstorming

---

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