DDD分层架构

微服务架构模型有好多种，例如洋葱架构、CQRS和六边形架构等。虽然这些架构模式提出的时代和背景不同，但其核心理念都是为了设计出"高内聚，低耦合"的微服务，轻松实现微服务的架构演进。DDD分层架构的出现，使微服务的架构边界变得越来越清晰，在微服务架构模型中，占有非常重要的位置。

什么是DDD分层架构

DDD分层架构其实也在不断发展和演进。早期的DDD分层架构是一种各层都依赖于基础层的传统四层架构，后来这种四层架构进一步优化，实现了各层对基础层的解耦和依赖倒置。

用户接口层

在很多描述DDD用户接口层的文章中，对用户接口层的解释通常都是这样的："用户接口层负责向用户显示信息和解释用户指令，这里的用户可能是用户、程序、自动化测试和批处理脚本等。"

但随着微服务架构的盛行，大多数应用都采用了前后端分离的设计模式。为了连接前端应用和后端微服务，于是又出现了API网关。

结合洋葱模型和端口适配器架构模型，我在这里稍微拓展一下用户接口层的作用。

在微服务面向不同前端应用时，同样的一段业务逻辑，可能由于渠道不同，而在前端展示的页面要素不同，因此要求后端微服务返回的数据结果会不同。比如在面向内部员工的PC端应用时，可能要求返回某些对象的全部属性的数据，而在面向外部客户的移动端应用时，可能只需要返回几个关键属性的数据就可以了。

为了避免暴露微服务的核心业务逻辑，防止数据外泄，不能将后端对象的所有属性数据，不加区分地暴露给所有前端应用；更不能仅仅因为前端应用不同的数据展示需求，而在后端定制开发出多个不同的应用服务或领域服务，面向前端应用提供不同的服务适配。这样容易产生大量重复代码，也容易导致业务逻辑混乱，代码可维护性变差。

这时用户接口层的facade服务和数据组装器Assembler就可以发挥作用了。facade服务可以封装应用服务，适配不同前端应用的集成技术体系，提供不同类型的服务接口适配，而数据组装器Assembler可以根据不同前端应用的数据需求，完成前端DTO和后端DO对象的组装和转换等操作，按需提供数据适配。我们基本不再需要调整领域模型的核心领域逻辑，就可以面向不同前端应用提供灵活的接口定制和数据适配。

因此，用户接口层面向前端应用的灵活的适配能力，可以保证应用层和领域层核心领域逻辑的稳定。

用户接口层在前后端分离设计时，主要完成后端微服务与前端不同用户的接口和数据适配。这里的用户仍然可以是用户、程序、自动化测试和批处理脚本等。而作为需要复用的中台微服务的用户接口层，它还可以面向不同的商业生态，适配不同业务接入方的集成技术体系和要求，提供灵活的服务接入和适配能力。

用户接口层主要有facade接口、DTO以及DO数据的组装和转换等代码逻辑。

应用层

应用层连接用户接口层和领域层，它是很薄的一层，主要职能是协调领域层多个聚合完成服务的组合和编排。

应用层之下是领域层，领域层是由多个业务职责单一的聚合构成，实现核心的领域逻辑。应用层负责协调领域层多个聚合的领域服务，面向用例和业务流程完成服务的组合和编排。所以理论上应用层不应该实现领域模型的核心领域逻辑。这也是应用层为什么会很薄的原因。

应用层之上是用户接口层，在应用层完成领域层服务组合和编排后，应用服务被用户接口层Facade服务封装，完成接口和数据适配后，以粗粒度的服务通过API网关面向前端应用发布。

此外，应用层也是微服务之间服务调用的通道，微服务在应用层可以调用其他微服务的应用服务，完成微服务之间的服务组合和编排。

在应用层主要有应用服务、事件订阅和发布等相关代码逻辑。其中，应用服务主要负责服务的组合、编排和转发，处理业务用例的执行顺序以及结果的拼装。在应用服务中还可以进行安全认证、权限校验、事务控制、领域事件发布或订阅等。

注意

在微服务设计和开发时，应用层的主要职能是服务的组合和编排。切记不要将本该在领域层的核心领域逻辑在应用层实现，这会使得领域模型失焦，时间一长应用层和领域层的边界就会变得混乱，边界清晰的四层架构慢慢就可能演变成业务逻辑混杂的三层架构了。

领域层

领域层位于应用层之下，是领域模型的核心，主要实现领域模型的核心业务逻辑，体现领域模型的业务能力。领域层用于表达业务概念、业务状态和业务规则，可以通过各种业务规则校验手段保证业务的正确性。

在设计时，领域层主要关注实现领域对象或者聚合自身的原子业务逻辑，不太关注外部用户操作或者流程等方面的业务逻辑。所以在领域层主要体现的是领域模型的能力。外部易变的如流程、业务组合和编排的需求由应用层完成。这样设计可以保证领域模型不易受外部需求变化的影响，从而保证领域模型的稳定。

领域建模时提取的大部分领域对象都放在领域层。微服务的领域层可能会有多个聚合，聚合内部一般都有聚合根、实体、值对象和领域服务等领域对象。它们组合在一起协同实现领域模型的核心业务能力。

这里我要特别解释一下聚合中几个领域对象的关系，以便你在设计领域层的时候能更加清楚。领域模型的业务逻辑主要是由实体和领域服务来实现的。其中实体会采用充血模型来实现所有与之相关的业务功能。但实体对象和领域服务在实现业务逻辑上不是同一层级的。当领域中的某些功能，如单一实体（或者值对象）不能实现时，这时领域服务就会出马，组合和协调聚合内的多个实体（或者值对象），实现复杂的业务逻辑。

注意

在选择用实体方法或者领域服务实现业务逻辑时，请记住不要滥用领域服务。如果单一实体自身的业务行为也用领域服务来实现，这样就很容易变成贫血模型。

基础层

基础层贯穿了DDD所有层，它的主要职能就是为其他各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。常见的功能是完成实体的数据库持久化。

基础层主要有仓储服务代码逻辑。仓储采用依赖倒置设计，封装基础资源逻辑的服务实现，实现应用层、领域层与基础层的解耦，降低外部资源变化对领域逻辑的影响。

DDD分层架构的重要原则

在《实现领域驱动设计》书中提到，DDD分层架构有一个重要的依赖原则："每层只能与位于其下方的层发生耦合。"

根据耦合的紧密程度可以分为两种架构模式：严格分层架构和松散分层架构。

严格分层架构是指任何层只能对位于其直接下方的层产生依赖，而松散分层架构则允许某层与其任意下方的层发生依赖。优化后的DDD分层架构模型就属于严格分层架构，而传统的DDD分层架构则属于松散分层架构。

DDD分层架构如何推动架构演进

业务和技术都不是一成不变的，领域模型也会随着业务发展不断变化和演进，而领域模型的演进又会直接影响微服务的功能和边界。那如何实现领域模型和微服务的同步演进呢？下面我们将从两方面展开详细分析。

微服务架构的演进

在DDD的领域层主要有：领域服务、值对象、实体、聚合根和聚合等。一般来说实体或值对象的简单变更，不会让领域模型和微服务发生太大变化，但聚合的重组或拆分却可以。这是因为聚合业务功能内聚，能独立完成特定业务领域的业务逻辑。所以聚合重组或拆分，势必会引起领域模型和微服务的系统功能变化。

这里我们可以以聚合作为组合和拆分的基本单元，完成领域模型和微服务架构的演进。我们可以将聚合作为一个完整单元，在不同的领域模型之间完成重组或者拆分，甚至可以直接将一个聚合独立拆分为微服务。

好的聚合和代码模型的边界设计，可以让你快速应对外部业务的频繁变化，轻松实现领域模型和微服务架构的演进。

微服务内服务的演进

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

领域层通常只提供一些原子服务，比如领域服务a、b、c。在服务设计时，你并不一定能预测到这些服务会被多少个上层服务组装。但随着系统功能增强和外部接入越来越多，应用服务会不断丰富。有一天你发现领域服务b和c同时多次被应用层的应用服务A和B组装和调用了，在A和B内它们的业务执行逻辑也基本一致。这时你就可以考虑将领域服务b和c的功能合并，并将合并后的功能下沉到领域层，演进为新的领域服务（b+c）。这样既减少了领域服务的数量，又降低了上层应用服务组合和编排的复杂度。

这就是服务演进的过程。它们会随着业务和应用的发展而不断演进和沉淀。最后你会发现你的领域模型变得越来越精炼，微服务也越来越能够适应需求的快速变化了。

三层架构如何演进到DDD分层架构

综合上面的讲解，相信你对DDD分层架构的优势有了一定了解。这里我们不妨总结一下DDD分层架构最重要的两点优势。

▪首先，由于层间松耦合，我们可以专注本层的设计和开发，而不必关心其他层，也不必担心本层设计时会影响其他层。DDD分层架构成功地降低了层与层之间的依赖。

▪其次，DDD分层架构使得程序的结构变得更加清晰，升级和维护变得更加容易。我们在修改某层代码时，只要本层服务的接口参数不变，其他层可以不必修改。即使本层的接口发生变化，也只影响相邻的上层，修改工作量小且范围可以控制，不会带来意外的风险。

那么，传统企业架构应该如何转向DDD分层架构呢？我们不妨来看看下面的内容。

传统企业应用大多是单体架构，而单体架构大多采用三层架构。三层架构可以部分解决程序内代码间调用复杂、代码职责不清的问题，但这种分层是逻辑概念，在物理上它仍然是中心化的集中式架构，所以并不适合分布式微服务架构。

其实，DDD分层架构内的基本要素和三层架构类似，只不过在DDD分层架构中，这些要素被重新归类，划分到了不同的层，确定了层与层之间的交互规则和职责边界。

在三层架构向DDD分层架构演进时，主要变化发生在业务逻辑层和数据访问层。

我们先来看一下业务逻辑层的变化。DDD分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱、代码改动相互影响大的问题。DDD分层架构将三层架构业务逻辑层的业务逻辑拆分到了应用层和领域层，分别以应用服务和领域服务等形式存在。应用服务实现服务的组合和编排，领域服务完成核心领域逻辑，应用服务可以快速响应前端业务和流程的变化，而领域层则更加专注领域模型和实现领域逻辑。

我们再来看一下数据访问层的变化。这个变化主要发生在数据访问层和基础层之间。三层架构数据访问采用DAO方式，而DDD分层架构对数据库等基础资源访问时采用了仓储设计模式，领域层可以通过仓储接口访问基础资源的实现逻辑。这样，通过依赖倒置实现了各层对基础资源的解耦。原来三层架构的第三方工具包、驱动、Common、Utility、Config等通用的、公共的基础资源统一放到了基础层。

另外，DDD分层架构在用户接口层引入了DTO和facade接口，可以给前端应用提供更灵活的数据和接口适配能力。

小结

DDD分层架构是微服务设计和开发的核心框架。通过用户接口层、应用层、领域层和基础层这些层次划分，可以明确微服务内各层的职能，划定各领域对象的边界，确定各领域对象的依赖和协作方式。

DDD分层架构也是微服务代码模型设计的主要参考依据。这种架构的分层，既体现了微服务设计和架构演进的需求，又很好地融入了领域模型的概念，二者无缝结合，相信能够给你的微服务设计带来不一样的体验。