转载

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

领域驱动设计(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) 就是一种实现这种分离的技术:

  • 命令作用于写入模型上,并且要以一致的方式进行修改,最好是在一个 聚集(aggregate) 上,它会产生一个或多个事件。Miles指出所创建出来的事件并不是副产品,它们是命令的实际结果。
  • 查询使用一个或多个读取模型,针对查询会进行一些优化。写入模型所生成的事件会被读取模型接受到,读取模型会进行更新,从而反映写入模型的状态。

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

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

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

原文  http://www.infoq.com/cn/news/2017/01/microservices-events-ddd
正文到此结束
Loading...