大家好，在当前技术架构领域，总是会把微服务和 DDD 联结在一起，今天就和大家聊聊为什么微服务设计会选择 DDD？

微服务的困境

在软件开发的演进历程中，微服务架构以其独特的优势解决了集中式单体应用的诸多局限，比如扩展性、弹性伸缩、敏捷开发等问题，然而，微服务本身并非是一把万能钥匙，它出现之后同样也带来了新的挑战：

1. 服务粒度的确定难
2. 服务的拆分和设计难
3. 服务边界的定义难

当然还有其他一些挑战的存在，其实在灸哥看来，这些问题和挑战的核心都在于对业务或者说服务的边界缺乏清晰的认知。

微服务架构的提出者 Martin Fowler 本身是没有给出服务拆分的具体指导方法的，随着不停地实践和演进，业界对此也开始出现各种不同的声音：

1. 有人认为微服务仅仅就是单体应用的简单拆分，就是把原来一个单体拆分成多个部署包或者把单体应用架构替换成一套支持微服务架构的技术框架，比如 Spring Cloud 等
2. 有人认为服务越小越好，拆的越小效果越好

但这么认为的结果是什么呢？不约而同都失败了，近些年圈子里开始有很多人抱怨一些项目因为前期的微服务拆分过度，导致项目复杂度过高，无法上线和运维。

所以，灸哥认为导致微服务拆分困境的根本原因是在于这帮“伪”架构师们不知道业务或者微服务的边界到底在什么地方。

DDD：微服务设计的新时代

2004年，Eric Evans的《领域驱动设计》一书的发表，标志着 DDD 的诞生。DDD 通过领域模型定义业务和应用边界，确保业务模型与代码模型的一致性。

但是 DDD 提出后，在业内一直都是“雷声大、雨点小”，直到 Martin Fowler 提出微服务架构后，DDD 才真正迎来了自己的时代。

为什么DDD适合微服务

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

各位在这里要先明确下 DDD 的定位：DDD 不是架构，而是一种架构设计方法论，它通过边界划分简化复杂业务领域，设计清晰的领域和应用边界，实现架构演进。

DDD的应用

DDD 的战略设计从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，为微服务设计提供参考边界。

DDD 的战术设计则是从技术视角出发，侧重领域模型的技术实现，涵盖聚合根、实体、值对象、领域服务等。

划定领域模型和微服务边界的三板斧

1. 通过事件风暴梳理业务过程中的用户操作、事件以及外部依赖关系，识别出领域实体等领域对象
2. 基于领域实体之间的业务关联性，把业务紧密相关的实体进行组合形成聚合，并确定聚合根、值对象和实体，聚合之间的边界是第一层边界，在同一个微服务实例中运行，属于逻辑边界
3. 根据业务语义边界，将一个或多个聚合划定在限界上下文中，形成领域模型，限界上下文之间的边界是第二层边界，可能就是微服务的边界，属于物理边界

确定好逻辑边界和物理边界之后，再来进行微服务的设计就不是难事了，DDD 不仅可以用于微服务的设计，还可以很好地应用于企业中台的设计，如果你的企业正在做中台转型，那 DDD 会是一个很好的工具。

DDD 与微服务的和谐共舞

DDD 作为一种架构设计方法，与作为一种架构风格的微服务，两者共同追求着：

1. 对业务需求的高响应力
2. 从业务视角分离应用系统建设的复杂度
3. 从业务出发，根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，保持架构和代码的持续生命力（演进式架构和演进式代码）

DDD 关注从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象建立领域模型，维持业务和代码的逻辑一致性。

微服务更多地关注运行时通信、容错、故障隔离、数据管理、服务治理，关注微服务的独立开发、测试、构建和部署。

基于 DDD 的微服务架构设计指导

DDD分层架构设计包括用户接口层、应用层、领域层和基础层。每层都扮演着特定的角色，并通过严格的分层原则实现松耦合，简化升级和维护。

用户接口层

负责向用户显示信息和执行用户指令。这里的用户可能是：用户、程序、自动化测试和批处理脚本等。

应用层

比较薄，理论上不包括业务规则和逻辑，主要面向用例和流程相关的操作。

在 DDD 的分层架构中，应用层在领域层之上，领域层中包含多个聚合，应用层承担了协调多个聚合的服务和领域对象完成服务的编排和组合，协调完成业务操作。

应用层也是微服务之间交互的通道，可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。

提醒：尽量千万不要把应该在领域层的业务逻辑放在应用层中，长期下去，应用层和领域层边界模糊，四层架构演化成三层架构了，业务逻辑变得混乱。

领域层

实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。

主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。

基础层

贯穿所有层，为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。

DDD的分层架构有着一个非常重要的原则：每层只能与位于下方的层发生耦合。

微服务架构的演进

微服务间的架构演进

领域模型不是一成不变的，它的演进和变化影响着领域模型，而领域模型的演进和变化则会影响着微服务的功能和边界。

微服务架构的演化策略，如服务拆分和聚合迁移，都依赖于对聚合之间边界的清晰定义。

如上图所示：

1. 微服务 1 中聚合 a 被高频访问，导致微服务 1 整体性能被拖垮。于是采取微服务架构演化策略：把聚合 a 从微服务 1 中剥离出来，独立为微服务 2，单独轻松应对高频访问场景。
2. 随着业务发展到一定阶段，微服务 3 的领域模型发生变化，聚合 d 更适合到微服务 1 的领域模型中。于是演化策略：把聚合 d 迁移到微服务 1 中。如果在设计的时候对聚合之间的边界有很好的定义，这个迁移的过程就不会太复杂，时间花费也比较低

微服务内的架构演进

在微服务内部，实体的方法被领域服务组合和封装，领域服务又被应用服务组合和封装。在服务逐层组合和封装的过程中，你会发现这样一个有趣的现象：

在服务设计时，当你并不一定能完整预测有哪些下层服务会被多少个上层服务组装，此时采取的策略是：领域层通常只提供一些原子服务，比如领域服务 a、b、c。

随着系统功能增强和外部接入越来越多，应用服务会不断丰富。你会发现领域服务 b 和 c 同时多次被多个应用服务调用了，执行顺序也基本一致。这时就要把 b 和 c 合并，再将应用服务中 b、c 的功能下沉到领域层，演进为新的领域服务（b+c）。这样既减少了服务的数量，也减轻了上层服务组合和编排的复杂度。

三层架构向 DDD 分层架构的演进

DDD分层架构的优势在于层间松耦合、清晰的程序结构、易于升级和维护。

传统的软件架构大多都是单体三层架构，解决了程序内代码间调用复杂、代码职责不清的问题，但属于逻辑分层概念，物理上依旧是中心化的集中式架构。

两者都是分层架构，在传统单体三层架构向 DDD 分层架构的演进过程，就是需要重新归类要素、重新划分层次、重新确定交互规则和职责边界。

微服务架构与 DDD 的结合，为现代软件系统的设计和开发提供了一条清晰的路径。

DDD 不仅为微服务设计提供了理论基础和实践指导，还帮助企业构建响应迅速、易于维护和扩展的系统。

随着技术的不断演进，DDD 和微服务的融合将引领我们走向更加高效和创新的软件开发新时代。