DDD领域驱动设计微服务架构——知识点笔记_微服务ddd架构各模块职责

目录

 一、架构概览与演变

1.1 整洁架构：​编辑1.2 六边形架构

1.3 DDD 分层架构

1.4 三层架构

1.5 三层架构到DDD架构的演变

二、DDD架构代码目录详解 

 2.1 用户接口层

2.2  应用层 

2.3 领域层 

2.4 基础层

2.5 各层代码调用案例展示

---

 一、架构概览与演变

1.1 整洁架构：1.2 六边形架构

1.3 DDD 分层架构

1. 接口层负责与用户、程序、自动化测试、批处理脚本交互。
2. 应用层负责对领域层的多个聚合进行协调，通俗地说就是对微服务之间进行组合编排，但不负责具体的微服务实现逻辑，实现逻辑应该放在领域层。应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
3. 领域层实现微服务核心业务逻辑，包含聚合根、实体、值对象、领域服务等领域对象（领域模型），其中的实体采用充血模型（对象的方法和数据不分离，与之对应的是贫血模型）实现；领域服务负责组合聚合内的多个实体来实现复杂业务。
4. 基础层贯穿所有层，为其他层提供三方工具、驱动、MQ、网关、文件操作、缓存、数据库等基础服务，封装基础服务的特点实现了以上三层的解耦。

1.4 三层架构

传统三层架构包含Controller层、Service层、Dao层，增删改查的流程大概如下：

但其实可以发现，Service层就是充当了中间人，Controller明明可以直接调用Dao，但真实业务场景往往更复杂，前后端交互是用Json（对象）交互，因为有时候前后端需要交互的数据并不是对象所有的字段，只是其中某些字段，那我们传输时只需要传这几个字段就行了，所以需要诞生PO、VO、DTO，这就不再是纯粹的三层架构了。

1. VO 是Value Object 的缩写，值对象，位于视图层，每一个字段与视图层所需要的字段对应
2. DTO是Data Transfer Object 的缩写，数据传输对象，在视图层和服务层之间传输用来转换从PO到VO，或者从VO到PO的中间对象
3. PO 是Persistent Object 的缩写，持久化对象，位于持久层，每一个字段，与数据库相对应
4.  DO（Domain Object）领域对象，微服务运行时的实体，是核心业务的载体，出现在领域模型中。

1.5 三层架构到DDD架构的演变

1.  在三层架构中的业务逻辑层和数据访问层发生了较多的改变。
2. DDD架构在业务接口层引入DTO，用户接口可以更灵活的交互数据。
3. 三层架构的业务层往往是混乱复杂的，DDD架构将其拆分到了应用层和领域层，应用层响应前端，调用领域层的核心业务进行服务。
4. 在最底层，三层架构使用Dao访问数据，DDD架构使用仓储模式Repository，通过依赖倒置实现基础资源解耦，像驱动、三方工具包等公共资源都被归到了基础层。

二、DDD架构代码目录详解 

DDD分层架构、六边形架构、整洁架构都实现了前后端分离，内部负责业务逻辑、外部负责交互用户和基础资源，不同的是DDD分离出来了应用层，来充当API角色，解决了传统三层架构中Service层混乱无序的问题，以下是一个经典DDD架构模型代码目录：

 2.1 用户接口层

interfaces存放与前端交互，展示数据的代码。主要处理用户的Restful请求，解析配置文件，传递数据往应用层。

• assemble： 实现领域对象和DTO之间的数据交互。
• dto：进行数据传输，实现了领域对象与外界的隔离。
• facade：提供粗粒度的API，委托和分发用户的请求给应用服务。

2.2  应用层 

application存放与微服务组合和编排相关代码。

 

• event：与事件相关，负责事件的发布与订阅。
• Service：对领域服务或外部应用服务进行封装、编排或组合，一般包含多个应用服务类。

2.3 领域层 

domain存放核心业务逻辑代码。包含多个聚合代码包，聚合包内包括实体、方法、领域服务和事件等代码。

• aggregate（聚合）：是高内聚的业务逻辑封装，聚合间代码边界清晰，方便微服务重组。
• entity（实体）：存放聚合根、实体、值对象、工厂模式相关代码。采用充血模式，同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码在领域服务中实现。
• event（事件）：存放事件实体以及与事件活动相关的业务逻辑代码。
• Service（领域服务）：存放领域服务代码。包含一个或多个领域服务类，封装成实体或方法后向上层提供调用接口。
• repository（仓储）：存放所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法。一个聚合对应一个仓储。

2.4 基础层

infrastructure存放基础资源代码。为其它各层提供的通用技术能力、三方软件包、数据库服务、配置、网关等基础资源服务。

• Config：主要存放配置相关代码。
• Util：主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码，你可以为不同的资源类别建立不同的子目录。

2.5 各层代码调用案例展示

 DDD分层架构不允许服务跨层调用，服务逐层封装

1. 基础层的主要对象是 PO 对象。我们需要先建立 DO 和 PO 的映射关系：大多数情况下 PO 和 DO 是一一对应的。但也有 DO 和 PO 多对多的情况，在 DO 和 PO 数据转换时，需要进行数据重组。
2. 领域层的主要对象是 DO 对象。DO 是实体和值对象的数据和业务行为载体，承载着基础的核心业务逻辑。通过 DO 和 PO 转换，我们可以完成数据持久化和初始化。
3. 应用层的主要对象是 DO 对象。如果需要调用其它微服务的应用服务，DO 会转换为 DTO，完成跨微服务的数据组装和传输。用户接口层先完成 DTO 到 DO 的转换，然后应用服务接收 DO 进行业务处理。如果 DTO 与 DO 是一对多的关系，这时就需要进行 DO 数据重组。
4. 用户接口层会完成 DO 和 DTO 的互转，完成微服务与前端应用数据交互及转换。Facade 服务会对多个 DO 对象进行组装，转换为 DTO 对象，向前端应用完成数据转换和传输。
5. 前端应用主要是 VO 对象。展现层使用 VO 进行界面展示，通过用户接口层与应用层采用 DTO 对象进行数据交互。

 

---

参考资料领域驱动实践架构分析与代码设计_l领域驱动实践总结-CSDN博客