BT

您是否属于早期采用者或者创新人士?InfoQ正在努力为您设计更多新功能。了解更多

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

| 作者 Jan Stenberg ,译者 张卫滨 发布于 2017年1月9日. 估计阅读时间: 不到一分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!

领域驱动设计(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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT