微服务为什么要选择DDD

最近几年微服务架构非常火爆，很多企业也正在尝试从单体架构向微服务架构转型。微服务也已经成为很多企业实施中台战略的不二之选。技术人员之间不谈点微服务相关的技术，似乎就有点跟不上时代的感觉。

然而，从微服务提出到现在也已经过去好几年的时间了，很多企业在微服务实施过程中尝到了不少甜头，但是单体应用到底应该如何拆分微服务？微服务应该如何设计？这始终是项目团队面临的一个难题。

在微服务设计过程中，很多人都会纠结微服务边界的划定。我也经常看到项目团队在微服务拆分时，为微服务到底应该拆多小而争得面红耳赤。团队中不同的人会根据自己的经验和对微服务的理解，拆分出不同边界的微服务。大家各执一词，谁也说服不了谁。

那在实际落地过程中，我也确实见过不少项目在面临这种微服务拆分和设计的困惑时，是靠拍脑袋决定“的。可想而知，后续微服务架构的演进和运维自然会面临很多压力。

那是否有合适的理论或设计方法来指导微服务设计呢？

当你看到这一章的题目时，我想你已经知道答案了。

没错，就是DDD！

软件架构的演进史

我们知道，软件架构的演变和发展往往跟设备和技术的发展是正相关的。这些年随着设备和新技术的发展，软件的架构模式发生了很大变化。

软件的架构模式大体来说经历了从单机、集中式到分布式微服务架构三个阶段的演进。而近几年，随着分布式技术的快速兴起，我们已经迈入了微服务架构时代。

• 第一阶段是单机架构，这个阶段通常采用面向过程的设计方法，系统包括客户端UI层和数据库两层。通常采用C/S架构，大多采用结构化编程方式，系统围绕数据库驱动设计和开发，总是从设计数据库和字段开始。
• 第二阶段是集中式架构，这个阶段通常采用面向对象的设计方法。一般采用经典的三层架构，系统包括业务接入层、业务逻辑层和数据库层。传统单体应用大多采用集中式架构，这种设计模式往往容易使系统变得臃肿，可扩展性和弹性伸缩能力差。
• 第三阶段是分布式微服务架构，随着微服务架构理念的提出，单体集中式架构正在向分布式微服务架构演进。微服务架构可以实现业务和应用之间的解耦，解决集中式单体应用扩展性和弹性伸缩能力不足的问题，更加适合云计算环境下的部署和运营。

我们知道，在单机和集中式架构时代，大多采用瀑布开发模式。系统分析、设计和开发往往是独立、分阶段割裂进行的。比如，在系统建设过程中，我们经常会看到这样的情形：A负责提出需求，B负责需求分析，C负责系统设计，D负责代码实现，这样的流程很长，经手的人也很多，很容易导致信息丢失。最后，就很容易导致需求、设计与代码实现的不一致，往往到了软件上线后我们才发现很多功能并不是自己想要的，或者做出来的功能跟自己提出的需求偏差太大。软件无法快速响应需求和业务的迅速变化，最终企业错失发展良机。

此时，分布式微服务架构的出现就有点恰逢其时了。

微服务拆分和设计的困境

进入微服务架构时代以后，微服务确实也解决了原来单体应用的很多问题，比如扩展性、弹性伸缩能力、小规模团队的敏捷开发等。但在看到这些好处的同时，在微服务实践过程中也产生了不少争论和疑惑。比如，微服务的粒度应该如何把握？微服务到底应该如何拆分和设计呢？微服务的边界到底应该在哪里？

可以说，很久以来都没有一套系统的理论和方法来指导微服务的拆分和设计。于是，在很长的一段时间内，有不少人对微服务的拆分和设计产生了一些曲解。有人认为：“微服务其实很简单，就是把原来一个单体应用包拆分为多个部署包，或者将原来的单体集中式架构，替换为一套支持微服务架构的分布式技术框架。”还有人说：“微服务嘛，就是要微、要小，拆得越小效果会越好。”另外还有“多个微服务是否可以共享一个数据库？”等诸如此类的问题。

我想，这两年，你在IT技术圈中也可能听说过某些项目因为微服务拆分过度，导致项目复杂度过高，无法上线和运维的事情。

综合来看，我认为微服务拆分困境产生的根本原因，就是不知道业务或者应用的边界到底在什么地方。换句话说，如果确定了业务边界和应用边界，这个困境也就迎刃而解了。

从很多微服务实践和企业最终目标来看，其实有时候微服务设计的重点不在于微服务的大小，也不在于拆分出多少个微服务，而是在于微服务内外部的边界是否清晰，这些边界是否进行了有效隔离，以及这些微服务上线后能否随着业务的发展轻松实现业务模型和微服务架构的演进。所以，在微服务设计时，我们要考虑微服务拆分的大小，也要关注微服务内部的逻辑边界。

微服务设计强调从业务领域出发，因此单体应用向微服务架构演进时，我们第一步要做的就是先划分业务的领域边界，然后在这个边界内构建业务的领域模型，根据领域模型完成从单体应用到微服务的建设。这样每个业务领域都符合“高内聚，低耦合”的设计原则，未来微服务的架构演进就会变得更容易了。

DDD的核心思想是从业务视角出发，根据限界上下文边界划分业务的领域边界，定义领域模型，确定业务边界。在微服务落地时，建立业务领域模型与微服务代码模型的映射关系，从而保证业务架构与微服务系统架构的一致性。但DDD提出后在软件开发领域一直都是“雷声大，雨点小”！直到Martin Fowler提出微服务架构后，DDD才真正迎来了自己的时代。

微服务架构出现后，一些熟悉DDD设计方法的软件工程师在进行微服务设计时，发现可以利用DDD设计方法来建立领域模型，划分领域边界，再根据这些领域边界从业务视角来划分微服务边界。他们发现按照DDD方法设计出的微服务的业务和应用边界都非常合理，可以很好地满足微服务“高内聚，低耦合”的设计要求。于是越来越多的人开始将DDD作为领域建模和微服务设计的指导思想。

现在，越来越多的企业已经将DDD作为微服务设计的主流方法了。DDD也从过去“雷声大，雨点小”，开始真正火爆起来了。

为什么DDD适合微服务？

众里寻他千百度。蓦然回首，那人却在，灯火阑珊处。”在经历了多年的迷茫和争论后，微服务终于寻到了它的心上人，终于可以帮它解开微服务拆分和设计的心结了。

DDD是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。

DDD不是架构，它是一种架构设计方法论，它通过业务边界划分将复杂业务领域简单化，帮我们划分出清晰的业务领域和应用边界，从而可以很容易地实现微服务的架构演进。DDD的出现使得原来微服务拆分和设计过程中的问题不再是难题。

DDD包括战略设计和战术设计两部分，它们分别从不同的视角出发，完成领域建模和微服务的拆分和设计。

战略设计是从业务视角出发，划分业务的领域边界，建立基于通用语言和业务上下文语义边界的限界上下文，构建领域模型。而限界上下文就可以作为微服务拆分和设计的边界。

战术设计则是从技术视角出发，侧重于对领域模型的技术实现，按照领域模型完成微服务的开发和落地。在战术设计中会有聚合、聚合根、实体、值对象、领域服务、领域事件、应用服务和仓储等领域对象，这些领域对象会以代码的形式映射到微服务中，完成设计和系统落地。

在DDD战略设计过程中会对领域进行细分，划分出业务上下文边界，然后建立领域模型，上下文边界和领域模型可以作为微服务拆分和设计的输入，指导微服务落地时的拆分和设计。

DDD战略设计中的领域建模是一个从发散到收敛的过程，通常采用事件风暴工作坊方法。

事件风暴工作坊是一项团队活动，领域专家与项目团队通过头脑风暴的形式，罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对每一个事件标注出导致该事件的命令，再为每一个事件标注出命令发起方的角色。命令可以是用户发起，也可以是第三方系统调用或者定时器触发等，最后对事件进行分类，整理出实体、聚合、聚合根以及限界上下文。

首先，针对业务领域，通过用例分析、场景分析和用户旅程分析等方法，尽可能全面地、不遗漏地梳理业务领域，发现这些业务领域中的命令、领域事件、领域对象以及它们的业务行为，并梳理这些领域对象之间的关系，这是一个发散的过程。

然后，我们将事件风暴过程中提取的实体、值对象和聚合根等领域对象，从不同的维度进行聚类，形成如聚合和限界上下文等边界，并在限界上下文边界内建立领域模型，这是一个收敛的过程，收敛输出的结果就是领域模型

我们可以分三步来构建领域模型和划分微服务的边界。

第一步，在事件风暴中根据场景分析，梳理业务过程中的用户操作、领域事件以及与外部的依赖关系等，找出哪些业务对象产生了这些业务操作或行为，并根据这些业务对象梳理出实体等领域对象。

第二步，根据领域实体之间的业务关联性，找出聚合根，将业务紧密相关的、相互依赖的实体组合形成聚合，确定聚合中的聚合根、值对象和实体。在图3-2中，同一个限界上下文内，聚合之间的边界是微服务内部的第一层边界，这些聚合在同一个微服务实例内运行。这个边界是一个逻辑边界，所以用虚线表示。

第三步，根据业务语义环境及上下文边界等因素，将一个或者多个聚合划定在一个限界上下文内，构建领域模型。限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界。不同限界上下文内的领域模型的业务逻辑，被隔离在不同的微服务实例中运行，它们在物理上是相互隔离的，所以这一层边界是物理边界，边界之间用实线来表示。

我们有了聚合和限界上下文这两层边界，就知道业务领域的边界到底在哪里了，进而微服务的拆分和设计也就不再是什么难事了。

在战略设计中我们建立了领域模型，划定了业务领域的边界，建立了通用语言和限界上下文，确定了领域模型中各个领域对象的依赖关系。到这儿，业务端领域模型的设计工作就基本完成了，这个过程同时也基本确定了应用端的微服务边界。

在从领域模型向微服务落地的过程，即DDD从战略设计向战术设计的过程中，我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行映射和绑定。当业务发生变化，我们需要为了响应业务变化而调整业务架构和领域模型时，系统架构也会同时调整，并同步建立新的映射关系。

有了上面的讲解，现在我们不妨再次总结一下DDD与微服务的关系。

DDD是一种架构设计方法，微服务是一种架构风格，两者从本质上都是为了追求软件的高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务领域出发，根据业务的发展，合理划分业务领“域边界，采用分治策略，降低业务和软件开发的复杂度，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。

DDD作为一种通用的设计方法，它主要关注从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。而微服务作为领域模型的系统落地，它主要关注从领域模型到微服务的代码映射和落地，运行时的进程间通信、容错和故障隔离，实现去中心化的数据管理和服务治理，关注微服务的独立开发、测试、构建和部署。

小结

我们可以通过DDD战略和战术设计方法，划定业务领域边界，构建领域模型，用领域模型指导微服务拆分和设计，解决微服务的业务和应用边界难以划定的难题，同时解决微服务落地时设计的难题。

如果你的业务焦点在领域，并且你的业务可以构建出富领域模型，那么你就可以毫不犹豫地选择DDD作为微服务的设计方法！

其实，更为关键的一点是，DDD不仅可以指导微服务的边界划分和设计，也可以很好地应用于企业中台的领域建模设计，帮你建立一个边界清晰、可高度复用的企业级中台业务模型，完成微服务的落地。

DDD对设计和开发人员的要求相对较高，实现起来可能会有一定的复杂度。不同企业的研发管理能力和个人开发水平也会存在差异。尤其对于传统企业而言，在用DDD落地的过程中，可能会存在一些挑战和困难。不过总体来说，采用DDD设计方法，可以给你带来很大收益。

1）DDD是一套完整而系统的设计方法，它可以帮你建立一套从战略设计到战术设计的标准设计过程，让你的中台和微服务设计思路更加清晰，设计过程更加规范。

2）DDD可以处理高复杂度业务领域的软件开发，通过分治策略降低业务和系统建设的复杂度，建立稳定的领域模型。

3）DDD在领域建模的过程中，强调项目团队与领域专家的合作，在团队内部可以建立良好的沟通氛围，建立团队通用语言。

4）DDD方法体系中有很多设计思想、原则与模式，深刻理解后可以帮你提高微服务架构的设计能力。

5）DDD不仅适用于微服务拆分和设计，同样也适用于单体应用。如果单体应用采用了DDD方法设计，当某一天你想将单体应用拆分为多个微服务时，你会发现采用DDD方法设计出来的单体应用，拆分起来比采用传统三层架构设计出来的单体应用容易很多。这是因为用DDD方法设计的单体应用，在应用内部会有很多聚合，聚合之间是松耦合的，但聚合内部的功能具有高内聚的特点。有了这一层清晰的聚合边界，我们就可以很容易完成从单体应用向微服务的拆分了。这个过程非常容易，不会花费太多时间。这种设计方式特别适合当前不具备微服务运行支撑能力，但又必须完成系统重构，待具备能力后再进行微服务拆分的项目。