总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 网络 「网络」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

整洁架构、CQRS、六边形架构等微服务架构都旨在“高内聚低耦合”。那DDD分层架构又如何？

1 DDD分层架构

1.1 分层架构的基本原则

每层只能与位于其下方的层发生耦合。

1.2 分层架构的分类

  • 严格分层架构(Strict Layers Architecture)

某层只能与其直接下层耦合，即我的奴隶的奴隶，不是我的奴隶。

  • 松散分层架构(Relaxed Layers Architecture)

允许任意上层与任意下层耦合。由于用户接口层和应用服务通常需要与基础设施打交道，许多系统都是该架构。

较低层有时也可与较高层耦合，但只限于采用观察者 (Observer)模式或者调停者(Mediator)模式场景。较低层 绝不能直接访问 较高层。例如，在使用调停者模式时，较高层可能实现了较低层的接口，然后将实现对象作为参数传递到较低层。当较低层调用该实现时， 它并不知道实现出自何处。

1.3 分层架构演进

1.3.1 传统四层架构

图片

将领域模型和业务逻辑分离出来，并减少对基础设施、用户界面甚至应用层逻辑的依赖，因为它们不属业务逻辑。将一个夏杂的系统分为不同的层，每层都应该具有良好的内聚性，并且只依赖于比其自身更低的层。

传统分层架构的 基础设施层 位于底层，持久化和消息机制便位于该层。这里的消息包含MQ消息、SMTP或文本消息(SMS)。可将基础设施层中所有组件看作应用程序的低层服务，较高层与该层发生耦合以复用技术基础设施。即便如此，依然应避免核心的领域模型对象与基础设施层直接耦合。

1.3.2 改良版四层架构

传统架构的缺陷

DDD初创开发团队发现，将基础设施层放在最底层存在缺点。比如此时领域层中的一些技术实现令人头疼：

  • 违背分层架构的基本原则
  • 难以编写测试用例

何解？

使用 依赖反转设计原则 ：低层服务（如基础设施层）应依赖高层组件（比如用户界面层、应用层和领域层）所提供接口。

应用依赖反转原则

  • 依赖反转原则后的分层方式：基础设施层在最上方，可实现所有其他层中定义的接口

图片

依赖反转原则真的可以支持所有层吗？

有人认为依赖反转原则中只存在两层：最上方和最下方，上层实现下层定义的抽象接口。因此上图的基础设施层将位于最上方，而用户接口层、应用层和领域层应作 同层且都位于下方 。对此大家可保留自己意见。在六边形［Cockburn］或端口和适配器架构中对此做详细讲解。

2 各层职责

2.1 用户接口层

一般包括用户接口、Web 服务等。

只处理用户显示和用户请求，不应包含领域或业务逻辑。有人可能认为，既然用户接口需验证用户输入，那就应该包含业务逻辑。事实上，用户接口所进行的验证和对领域模型的验证不同：对那些粗制滥造且只面向领域模型的验证行为，应该予以限制。

如果用户接口使用了领域模型中的对象，那么此时领域对象仅限于数据渲染展现。在采用这种方式时，可使用展现模型对用户接口与领域对象进行解耦。由于用户可能是人，也可能是其他系统，有时用户接口层将采用开放主机服务的方式向外提供API。用户接口层是应用层的直接用户。

用户接口层很重要，在于前后端调用的适配。若你的微服务要面向很多应用或渠道提供服务，而每个渠道的入参出参都不一样，你不太可能开发出太多应用服务，这样Facade接口就起很好的作用了，包括DO和DTO对象的组装和转换等。

2.2 应用层

主要包含应用服务，理论上不应有业务规则或逻辑，而主要是面向用例和流程相关的操作。

  • 应用层位于领域层之上，因为领域层包含多个聚合，所以它可协调 多个聚合服务和领域对象完成服务编排和组合 ，协作完成业务。
  • 应用层也是微服务间的交互通道，它可调用其它微服务，完成 微服务间的服务组合和编排 。

开发设计时，不要将本该放在领域层的业务逻辑放到应用层。因为庞大的应用层会使领域模型失焦，时间一长微服务就会演化为传统MVC三层架构，导致业务逻辑混乱。

应用服务是在应用层，负责服务的组合、编排、转发、转换和传递，处理业务用例的执行顺序以及结果的拼装，以粗粒度服务通过API网关发布到前端。还可进行安全认证、权限校验、事务控制、发送或订阅领域事件等。

2.3 领域层

主要包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。

实现核心业务逻辑，通过各种校验保证业务正确性。领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。

领域模型的业务逻辑主要由实体和领域服务实现：

  • 实体采用充血模型 实现所有与之相关的业务功能。

实体和领域服务在实现业务逻辑上不是同级，当领域中的某些功能，单一实体或值对象无法实现，就会用到领域服务，它可组合聚合内的多个实体或值对象，实现复杂业务逻辑。

2.4 基础层

为其它各层提供通用的技术基础服务，包含三方工具、驱动、MQ、API网关、文件、缓存、DB、基础服务等。最常用的还是提供DB持久化。

基础层包含基础服务，它采用依赖反转，封装基础资源服务，实现应用层、领域层与基础层解耦。

传统架构由于上层应用对DB强耦合，很多公司在架构演进最怕换DB，一旦更换，可能需重写一堆代码。但采用依赖反转，应用层即可通过解耦保持独立核心业务逻辑。当DB变更，只需更换DB基础服务。

3 微服务架构演进

领域模型中对象的层次从内到外依次是：值对象、实体、聚合和限界上下文。

实体或值对象的简单变更，一般不会让领域模型和微服务发生大变。但聚合的重组或拆分却可以。因为聚合内业务功能内聚，能独立完成特定业务。那聚合的重组或拆分，势必引起业务模块和系统功能变化。

可以聚合为基础单元，完成领域模型和微服务架构的演进。聚合可作为整体，在不同领域模型间重组或拆分，或直接将一个聚合独立为微服务。

微服务架构的演进案例

现有 微服务 1：包含聚合 a、b、c 微服务2：微服务3：包含聚合 d、e、f

  • 当发现微服务1中聚合a的功能经常被高频访问，以致拖累了整个微服务1的性能，可把聚合a，从微服务1中剥离，独立为微服务2以应对高性能场景
  • 随业务发展，发现微服务3的领域模型变化，聚合d会更适合放到微服务1的领域模型。即可将聚合d整体迁移到微服务1。注意定义好聚合间的代码边界
  • 架构演进后，微服务1从最初包含聚合a、b、c，演进为包含聚合b、c、d的新领域模型和微服务

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

微服务内服务的演进

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

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

你看，这就是服务演进的过程，它是随着你的系统发展的，最后你会发现你的领域模型会越来越精炼，越来越能适应需求的快速变化。

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

由于层间松耦合，我们可以专注于本层的设计，而不必关心其它层，也不必担心自己的设计会影响其它层。可以说，DDD成功地降低了层与层之间的依赖。

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

那我们该怎样转向DDD分层架构呢？不妨看看下面这个过程。

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

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

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

DDD分层架构在用户接口层引入了DTO，给前端提供了更多的可使用数据和更高的展示灵活性。

DDD分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。DDD分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。

另外一个重要的变化发生在数据访问层和基础层之间。三层架构数据访问采用DAO方式；DDD分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。

关于仓储。仓储本身属于基础层，但考虑到一个聚合对应一个仓储，为了以后聚合代码整体迁移方便，在微服务代码目录设计时，在聚合目录下增加一个Repository的仓储目录，跟仓储相关的代码都在这个目录下。

这个目录下的代码与聚合的其它业务代码是分开的。如果未来换数据库，只需将Repository目录下的代码替换。而如果聚合需要整体迁移到其它微服务中去，仓储的代码也会一并迁移。

仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config等通用的公共的资源类统一放到了基础层。

总结

DDD分层架构包含用户接口层、应用层、领域层和基础层。通过这些层次划分，我们可以明确微服务各层的职能，划定各领域对象的边界，确定各领域对象的协作方式。

文章目录
  1. 1. 1 DDD分层架构
    1. 1.1. 1.1 分层架构的基本原则
    2. 1.2. 1.2 分层架构的分类
    3. 1.3. 1.3 分层架构演进
      1. 1.3.1. 1.3.1 传统四层架构
      2. 1.3.2. 1.3.2 改良版四层架构
        1. 1.3.2.1. 传统架构的缺陷
        2. 1.3.2.2. 应用依赖反转原则
        3. 1.3.2.3. 依赖反转原则真的可以支持所有层吗？
  2. 2. 2 各层职责
    1. 2.1. 2.1 用户接口层
    2. 2.2. 2.2 应用层
    3. 2.3. 2.3 领域层
    4. 2.4. 2.4 基础层
  3. 3. 3 微服务架构演进
    1. 3.1. 微服务架构的演进案例
    2. 3.2. 微服务内服务的演进
    3. 3.3. 三层架构如何演进到DDD分层架构？
  4. 4. 总结