从事件和 DDD 入手来构建微服务

  • Jan Stenberg
  • 张卫滨

2017 年 1 月 8 日

话题:语言 & 开发架构

领域驱动设计(Domain-Driven Design,DDD)是一项很伟大的技术,它拉近了设计与程序实际所服务的领域,但是通常我们会关注结构,从而太早地做出决策,这并非 DDD 的本意。相反,在领域中,我们应该从事件开始,Russ Miles描述了在构建微服务时,采用“事件优先”的方式所具有的优势

Miles 认为除了关注结构之外,我们还过多地关注了通用语言(ubiquitous language),尤其是在领域对象方面更是如此。更糟糕的是,我们还会着手创建一些跨领域边界重用的库,这些库中包含了领域对象,这实际上阻碍了不同边界上下文(bounded context)的独立演化。

在 Miles 的经验中,对于企业级分层架构来说,这种方式已经成为了默认的架构风格,这么做的原因在于它能够让事情变得更容易,而不是更简洁或者有助于提升设计。这样做会带来一定的问题,比如实体变成了通用的,从只位于某个上下文之中变成了跨所有上下文的规范,这是与 DDD 的理念背道而驰的。

与上面提到的做法不同,Miles 宣称我们首先要从领域中发生了什么入手,也就是事件。在领域中,它们能够更好地捕获通用语言,通常也是描述领域的最简单的方式,尤其是在跟领域专家合作的时候更是如此。他发现无论是构建新的系统还是演化已有的系统,这种方式都非常适用。

Miles 主张在使用事件时,第一步是事件风暴(Event Storming),这是由Alberto Brandolini所创建的一项建模工作坊技术。其基本理念就是通过领域中所发生的事情(也就是领域事件)来探索这个领域,并且使用便签来描述领域中的事件,这些便签会沿着时间轴贴到一个很大的建模面板上。举例来说,能够引发事件的事情包括用户行为、外部系统所发生的事情以及时间的流逝。事件也有助于找到领域的边界,对术语的不同阐述可能就意味着存在边界。

对 Miles 来说,另外一个导致复杂性的地方在于为错误的工作任务使用错误的模型。针对状态的持久化,DDD 提供了 repository 模式,通常的做法是在读取和写入方面,使用相同的模型。这种方式带来的一个好处就是一致性,但是如果需求稍微有所差别,那么将读取和写入通过不同的模型进行分离将会取得明显的收益。

命令查询职责分离(Command Query Responsibility Segregation,CQRS)就是一种实现这种分离的技术:

事件溯源(Event sourcing)是对 CQRS 的自然扩展,在这里聚集产生的所有事件都会进行持久化,可以用来重新创建聚集的状态,而不是存储状态本身。按照 Miles 的说法,这种能力可以重建状态,是一种降低状态脆弱性的方法。

CQRS 以及事件溯源会带来其他的复杂性,比如最终一致性(eventual consistency);Greg Young是 CQRS 这个术语的创造者,他也对如今的事件溯源很感兴趣,他认为这两者都不是顶层的结构(top-level architecture)。按照 Young 的说法,它们只能有选择地应用于某些地方,他强调整个系统都基于事件溯源构建是一种反模式。

查看英文原文Start with Events and DDD When Building Microservices

语言 & 开发架构