DDD 分层架构的重要原则
在《实现领域驱动设计》书中提到，DDD 分层架构有一个重要的依赖原则:“每层只 能与位于其下方的层发生耦合。”
根据耦合的紧密程度可以分为两种架构模式:严格分层架构和松散分层架构。
严格分层架构是指任何层只能对位于其直接下方的层产生依赖，而松散分层架构则允 许某层与其任意下方的层发生依赖。从图 10-1 我们可以看出，优化后的 DDD 分层架构模 型就属于严格分层架构，而传统的 DDD 分层架构则属于松散分层架构。
那在设计时，我们应该选择什么样的架构模式呢?
综合我的经验，为了服务调用的可管理，我建议你采用严格分层架构，具体原因会在17.1 节详细介绍。
微服务架构的演进
业务和技术都不是一成不变的，领域模型也会随着业务发展不断变化和演进，而领域 模型的演进又会直接影响微服务的功能和边界。那如何实现领域模型和微服务的同步演进 呢?下面我们将从两方面展开详细分析。
在 DDD 的领域层主要有:领域服务、值对象、实体、聚合根和聚合等。一般来说实体 或值对象的简单变更，不会让领域模型和微服务发生太大变化，但聚合的重组或拆分却可 以。这是因为聚合业务功能内聚，能独立完成特定业务领域的业务逻辑。所以聚合重组或 拆分，势必会引起领域模型和微服务的系统功能变化。
这里我们可以以聚合作为组合和拆分的基本单元，完成领域模型和微服务架构的演进。我们可以将聚合作为一个完整单元，在不同的领域模型之间完成重组或者拆分，甚至可以 直接将一个聚合独立拆分为微服务。
下面结合图 10-3，以微服务 1 为例，讲解微服务架构的演进过程。
当你发现微服务 1 中聚合 a 的业务功能经常被高频访问，以致拖累整个微服务 1 的性 能时，可以将聚合 a 的代码整体从微服务 1 中剥离出来，独立为微服务 2。这样微服务 2 就 可轻松应对高性能需求的业务场景了。
在业务发展到一定阶段以后，你发现微服务 3 的领域模型有了变化，聚合 d 更适合放 到微服务 1 的领域模型中。这时你就可以将聚合 d 的代码整体搬迁到微服务 1 中。如果你 在微服务设计时，已经提前定义好了聚合之间的代码边界，那这个代码搬迁的过程就不会 太复杂，也不会花太多时间。
最后我们发现，在经历领域模型和微服务架构演进后，微服务 1 已经从最初包含聚合a、b、c，演进为包含聚合 b、c、d 的新微服务了，而微服务 1 中的聚合 a 也已经独立成微服务 2 了。
好的聚合和代码模型的边界设计，可以让你快速应对外部业务的频繁变化，轻松实现 领域模型和微服务架构的演进。
你可能还在想，怎样实现聚合代码的快速重组呢?别急，我会在第 14 章详细讲解。
微服务内服务的演进
在采用严格分层架构时，微服务内实体的方法会被领域服务组合和封装，领域服务又 会被应用服务组合和封装。在服务逐层组合和封装的过程中，你会发现这样一个有趣的现象。
我们看一下图 10-4。领域层通常只提供一些原子服务，比如领域服务 a、b、c。在服务设计时，你并不一定能预测到这些服务会被多少个上层服务组装。但随着系统功能增强和外部接入越来越多，应用服务会不断丰富。有一天你发现领域服务 b 和 c 同时多次被应用层的应用服务 A 和 B 组装和调用了，在 A 和 B 内它们的业务执行逻辑也基本一致。这时你 就可以考虑将领域服务 b 和 c 的功能合并，并将合并后的功能下沉到领域层，演进为新的领域服务(b+c)。这样既减少了领域服务的数量，又降低了上层应用服务组合和编排的复杂度。
这就是服务演进的过程。它们会随着业务和应用的发展而不断演进和沉淀。最后你会 发现你的领域模型变得越来越精炼，微服务也越来越能够适应需求的快速变化了。
三层架构如何演进到 DDD 分层架构
综合上面的讲解，相信你对 DDD 分层架构的优势有了一定了解。这里我们不妨总结一 下 DDD 分层架构最重要的两点优势。
- 首先，由于层间松耦合，我们可以专注本层的设计和开发，而不必关心其他层，也 不必担心本层设计时会影响其他层。DDD 分层架构成功地降低了层与层之间的依赖。
- 其次，DDD 分层架构使得程序的结构变得更加清晰，升级和维护变得更加容易。我 们在修改某层代码时，只要本层服务的接口参数不变，其他层可以不必修改。即使 本层的接口发生变化，也只影响相邻的上层，修改工作量小且范围可以控制，不会 带来意外的风险。
那么，传统企业架构应该如何转向 DDD 分层架构呢?我们不妨来看看下面的内容。
传统企业应用大多是单体架构，而单体架构大多采用三层架构。三层架构可以部分解 决程序内代码间调用复杂、代码职责不清的问题，但这种分层是逻辑概念，在物理上它仍 然是中心化的集中式架构，所以并不适合分布式微服务架构。
其实，DDD 分层架构内的基本要素和三层架构类似，只不过在 DDD 分层架构中，这 些要素被重新归类，划分到了不同的层，确定了层与层之间的交互规则和职责边界。
我们看一下图 10-5，分析一下从三层架构向 DDD 分层架构演进的主要变化。
由图 10-5 可知，在三层架构向 DDD 分层架构演进时，主要变化发生在业务逻辑层和 数据访问层。
我们先来看一下业务逻辑层的变化。DDD 分层架构对三层架构的业务逻辑层进行了更 清晰的划分，改善了三层架构核心业务逻辑混乱、代码改动相互影响大的问题。DDD 分层 架构将三层架构业务逻辑层的业务逻辑拆分到了应用层和领域层，分别以应用服务和领域服务等形式存在。应用服务实现服务的组合和编排，领域服务完成核心领域逻辑，应用服 务可以快速响应前端业务和流程的变化，而领域层则更加专注领域模型和实现领域逻辑。
我们再来看一下数据访问层的变化。这个变化主要发生在数据访问层和基础层之间。三层架构数据访问采用 DAO 方式，而 DDD 分层架构对数据库等基础资源访问时采用了 仓储设计模式，领域层可以通过仓储接口访问基础资源的实现逻辑。这样，通过依赖倒置 实现了各层对基础资源的解耦。原来三层架构的第三方工具包、驱动、Common、Utility、Config 等通用的、公共的基础资源统一放到了基础层。
另外，DDD 分层架构在用户接口层引入了 DTO 和 facade 接口，可以给前端应用提供 更灵活的数据和接口适配能力。
10.4本章小结
DDD 分层架构是微服务设计和开发的核心框架。通过用户接口层、应用层、领域层和 基础层这些层次划分，可以明确微服务内各层的职能，划定各领域对象的边界，确定各领 域对象的依赖和协作方式。
DDD 分层架构也是微服务代码模型设计的主要参考依据。这种架构的分层，既体现了 微服务设计和架构演进的需求，又很好地融入了领域模型的概念，二者无缝结合，相信能 够给你的微服务设计带来不一样的体验。
