DDD和Microservices的关系是什么？

Microservices（微服务架构）和DDD（领域驱动设计）是时下最煊赫一时的两个技术词汇。在最近两年的咨询工做中老是会被不一样的团队和角色询问，由此也促使我思考为何这两个技术词汇被这么深刻人心的绑定，它们之间的关系是什么呢？

服务于更高的业务响应力

从两个词汇的发明来看，它们是没有因果关系的。

DDD是Eric Evans于2003年出版的书名，同时也是这个架构设计方法名的起源。DDD的想法是让咱们的软件实现和一个演进的架构模型保持一致，而这个演进的模型来自于咱们的业务需求。这种演进式设计方法在当时看来仍是比较有挑战的，更为流行的解决架构设计复杂度的方法是分层：好比数据架构、服务架构、中间件架构等。MVC在互联网应用开发领域也基本成为了标配。

时间很快过了10年，Martin Fowler和ThoughtWorks英国架构师James Lewis坐下来一块儿分析了好几个可以持续演进的大型复杂系统，总结出了9大核心特质，而后用Microservices来定义了拥有这些特质的架构。以后因为Google、Netflix、Amazon等一系列明星企业都对号入座，Microservices开始风靡整个软件业。这时候不少人会问微服务架构是怎么设计出来的，业界人士会说DDD是一个好方法，其中也包括微服务定义者Martin Fowler，毕竟DDD原书的序是他给著的；）因而乎DDD开始在被定义10年后火了。

从我我的角度来看，若是真的须要找到因果关系，最根本的驱动力来自于科技时代对软件系统（数字化）响应力要求的不断提高，而系统的复杂度却随着业务的多元化而与日俱增。如何驾驭这样的高复杂度成了每一个企业必须面对的挑战，以致于业界开始把这种模型总结为响应力企业（Responsive Enterprise），而模型中总结的大部分原则都是为了更好的适应环境不肯定性带来的高复杂度。

从业务视角分离复杂度

每一个人可以认知的复杂度都是有限的，在面对高复杂度的时候咱们会作关注点分离，这是一个最基本的哲学原则。显然，在针对复杂业务场景进行建模时，咱们也会应用此原则。这个时候去分离关注点通常能够从两个维度出发：

• 技术维度分离，相似MVC这样的分层思想是咱们普遍接受的。
• 业务维度分离，根据不一样的业态来划分系统，好比按售前、销售、售后划分。

以上两个维度没有孰优孰劣之分，在处理复杂问题的时候必定都会用上，但为了高效响应业务的变化，微服务的架构更强调从业务维度的关注点分离来应对高复杂度。这是显著区别于传统SOA架构的特质之一，好比诞生于传统SOA时代的ESB（工业服务总线）就是一个典型的从技术关注点分离出来的中间件。

随着业务的变化，咱们也看到ESB成为了一个架构上的反模式，即大量的业务规则和流程被封装在了ESB里，让ESB成为了避免可驾驭的复杂度之源，以致于破坏了SOA架构以前承诺的各类优点。固然Microservices架构并不是是新一代SOA架构这么简单，已经有很多文章在讨论这个话题，本文就再也不展开了。

因此从本质上做为一种架构设计方法的DDD和做为一种架构风格的Microservices都是为着追求高响应力目标而从业务视角去分离复杂度的手段。

若是这个时代你还以为本身的架构不须要这种响应力，建议你问问身边维护3年以上系统的朋友或同事们，他们会告诉你这是怎样的一种痛苦。实际上不少企业对这种响应力的追求已经很“疯狂”了，这可能也是微服务的两位定义者都始料未及的。

他们在定义文章中带着很强警告语气让你们慎用，但在这个科技时代，微服务架构实施的可能风险对比高响应力在将来可能带来的市场机会几乎能够忽略不计。一个Netflix的成功就足以让大部分企业绝不犹豫的选择微服务做为自身的架构风格。

业务和技术渐进统一的架构设计

若是Microservices和DDD在目标上达成了上文的统一，那么在具体作法上和之前有什么不一样呢？

为了解释清楚这个问题让咱们将架构设计简化为如下三个层面工做：

• 业务架构：根据业务需求设计业务模块及交互关系。
• 系统架构：根据业务需求设计系统和子系统的模块。
• 技术架构：根据业务需求决定采用的技术及框架。

显然这三者在具体一个架构设计活动中应该是有前后顺序的，但并不是必定是孰先孰后，好比一个简单的web应用，不少人会说MVC是标配了（首先肯定了系统架构），或者有人说用RoR快（首先肯定了技术架构）。在给定的业务场景里，也许这样的顺序是合理的。

（架构设计工做分层及传统意义上的负责人）

这个时候我们增长复杂业务需求和快速市场变化这两个环境变量，这个顺序就变得颇有意思了。因而咱们听到很多走出初创期的互联网服务平台开始“重写”他们的系统（从PHP到Java），不少文章开始反思MVC带来的僵化（臃肿的展示层）。经历了这样变迁的架构师们都会感同身受的出来为DDD站台，其缘由就是“跳过”（或“后补”）业务架构显然代表设计出来的架构关注点并不在业务的响应力上，由于业务的可能变化点并无被分析出来指导系统和技术架构的设计。

DDD的核心诉求就是让业务架构和系统架构造成绑定关系，这样一来当咱们去响应业务变化调整业务架构时，系统架构的改变也会随之发生。

这个变化的结果有两个：

• 业务架构的梳理和系统架构的梳理是同步渐进的，其结果是划分出的业务上下文和系统模块结构是绑定的。
• 技术架构是解耦的，能够根据划分出来的业务上下文的系统架构选择最合适的实现技术。

第一点显然也是咱们产生微服务划分所必须遵循的，由于微服务追求的是业务层面的复用，因此设计出来的系统必须是跟业务一致的。第二点更是微服务架构的特质：“去中心化”的治理技术和数据管理。
做为架构设计的方法，DDD的各类实践，包括最近流行的Event Storming（事件风暴）实际上都是促进业务和系统架构梳理的渐进式认知。

在一次DDD工做坊中，一位同事给出了“大家连业务故事都讲不清楚，还有必要继续作架构设计吗？”这样的经典评论。而DDD的整个方法也没有涉及具体的技术架构实现，这个选型的权利不少时候被“下放”给了真正的开发团队。

值得一提的是采用DDD这种架构设计方法并不必定就产生Mircoservices这种架构风格，每每会推荐用大颗粒度的服务来包含业务分析过程当中发现的不肯定点，以免拆分后变化过分频繁带来的双向修改为本。

跨职能协做的架构设计

业务和系统的渐进认知改变了不少以前的架构工做模式，在采用DDD的过程当中，很容易感觉到业务专家的重要性。而若是还有人寄但愿让业务可以一次性给架构师讲清楚需求，那我建议抱有这样但愿的同窗去亲身参加一次本身不熟悉业务领域的架构设计讨论。你会很容易得出结论“原来业务也不懂他要什么”。固然业务人员据说要参加某种（软件）架构设计方法时内心也必定是抵触的。

DDD成功运用的基础就是创造让业务和系统这两种不一样认知模型逐步统一的环境。

（业务架构和系统架构设计）

因此“不幸”的是若是你不能创建一个跨业务和技术的新型架构设计小组，你的DDD实践就没有成功的基础，继而采用微服务架构可能就会是一场灾难。幸运的是这种跨职能组织结构已是前文中“采用”微服务架构企业（如Amazon）的标配，你没必要再论证这件事情的可实施性。剩下的关键就是如何可以让不一样背景的人们协做起来。这也是你们能够看到DDD领域的下一个热点，相似Event Storming这样的模式化协做工做坊会更多的出如今你们的视线里。

永无终止的DDD和演进的Microservices

DDD是容易上瘾的，当你们发现原来经过这个建模过程业务专家更了解服务划分（系统模块），架构设计更懂业务需求，这种协做会成为常态。在这个tech@core的时代，这样的融合将成为企业的核心竞争力。

固然刚开始采用DDD方法的时候，请不要认为每一个系统搞一次所谓的DDD工做坊就可以找到最佳的服务划分了。业务的变化是持续的，而每次业务架构变化必然牵动系统架构的变化。良好的领域架构绑定了业务和系统，让双方人员可以用统一语言交流，这件事情创建不易，而持续运做更难。

成功的DDD方法运用是贯穿系统的整个生命周期的，这个过程当中业务和技术的协做是持续发生的。

Microservices的最后一个特质：“演进式”设计 - 也明确了设计是一种持续的活动。DDD提供了一种符合这个微服务特质的工做方法，让演进可以落地。值得一提的是就笔者最近的经验，这个演进过程当中最难认知到变化的就是DDD里最显而易见的“统一语言”。当你们造成了一个业务概念-“客户”后，少有团队可以持续审视这个“客户”是否随着市场的变化而发生了含义的变迁。

对比传统的SOA，微服务的拆分也是动态的，禚娴静在本身的文章中描述一个系统采用微服务架构历程中服务拆分的演变。这里不会有一个ESB来以不变应万变，这种幻想在过去的10年里已经被数次打脸。DDD的好处是让业务和技术人员都可以在合做中理解这种变化，而不至于陷入业务人员抱怨技术架构不知所谓，技术人员以为业务人员朝秦暮楚的尴尬。

你须要成为那个高个子！

Martin Fowler在Microservies的定义文章中画了下面的图，评论“你必须有那个高度”来隐喻微服务实施的能力要求。就架构建模方面来讲我认为DDD应该是一个团队必须去掌握的，包括这个团队的业务人员和产品设计人员。

（微服务前置条件示意）

颇有意思的是目前Service Design也是全球用户体验设计领域的一个热门话题，从用户视角出发去设计整个服务链条。好比时下热门的共享单车，一个成功的服务设计应该是从用户开始有用车需求触发到最后完成骑行缴费离开，而不只仅是去设计一辆可以互联网解锁的自行车。

咱们能够找到不少Service Deisgn和DDD在原则上的类似之处，好比用户中心和协同设计。借用上面的高个子说法:

在业务需求认知和跨职能协做方面你必定须要成为高个子！

---

做为国内领域驱动设计（DDD）思想和实践的领军者，ThoughtWorks的架构咨询师们但愿和社区的合做伙伴一块儿，组织一次领域驱动设计的峰会，从而建立一个让国内的领域驱动设计（DDD）实践者们互相交流、分享本身团队的成功经验的机会。咱们也但愿经过这个大会，使得领域驱动设计（DDD）的架构思想可以在国内被更多人所认知，从而造成更大的规模效应。

咱们决定将于2017年12月8日、9日，在北京举行领域驱动设计中国峰会 2017（DDD China Conference 2017）。现向国内同行和领域驱动设计（DDD）的实践者们普遍征集话题：jinshuju.net/f/f8Puf5