目录
一、架构概览与演变
1.1 整洁架构:
1.2 六边形架构
1.3 DDD 分层架构
- 接口层负责与用户、程序、自动化测试、批处理脚本交互。
- 应用层负责对领域层的多个聚合进行协调,通俗地说就是对微服务之间进行组合编排,但不负责具体的微服务实现逻辑,实现逻辑应该放在领域层。应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
- 领域层实现微服务核心业务逻辑,包含聚合根、实体、值对象、领域服务等领域对象(领域模型),其中的实体采用充血模型(对象的方法和数据不分离,与之对应的是贫血模型)实现;领域服务负责组合聚合内的多个实体来实现复杂业务。
- 基础层贯穿所有层,为其他层提供三方工具、驱动、MQ、网关、文件操作、缓存、数据库等基础服务,封装基础服务的特点实现了以上三层的解耦。
1.4 三层架构
传统三层架构包含Controller层、Service层、Dao层,增删改查的流程大概如下:
但其实可以发现,Service层就是充当了中间人,Controller明明可以直接调用Dao,但真实业务场景往往更复杂,前后端交互是用Json(对象)交互,因为有时候前后端需要交互的数据并不是对象所有的字段,只是其中某些字段,那我们传输时只需要传这几个字段就行了,所以需要诞生PO、VO、DTO,这就不再是纯粹的三层架构了。
- VO 是Value Object 的缩写,值对象,位于视图层,每一个字段与视图层所需要的字段对应
- DTO是Data Transfer Object 的缩写,数据传输对象,在视图层和服务层之间传输用来转换从PO到VO,或者从VO到PO的中间对象
- PO 是Persistent Object 的缩写,持久化对象,位于持久层,每一个字段,与数据库相对应
- DO(Domain Object)领域对象,微服务运行时的实体,是核心业务的载体,出现在领域模型中。
1.5 三层架构到DDD架构的演变
- 在三层架构中的业务逻辑层和数据访问层发生了较多的改变。
- DDD架构在业务接口层引入DTO,用户接口可以更灵活的交互数据。
- 三层架构的业务层往往是混乱复杂的,DDD架构将其拆分到了应用层和领域层,应用层响应前端,调用领域层的核心业务进行服务。
- 在最底层,三层架构使用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分层架构不允许服务跨层调用,服务逐层封装
- 基础层的主要对象是 PO 对象。我们需要先建立 DO 和 PO 的映射关系:大多数情况下 PO 和 DO 是一一对应的。但也有 DO 和 PO 多对多的情况,在 DO 和 PO 数据转换时,需要进行数据重组。
- 领域层的主要对象是 DO 对象。DO 是实体和值对象的数据和业务行为载体,承载着基础的核心业务逻辑。通过 DO 和 PO 转换,我们可以完成数据持久化和初始化。
- 应用层的主要对象是 DO 对象。如果需要调用其它微服务的应用服务,DO 会转换为 DTO,完成跨微服务的数据组装和传输。用户接口层先完成 DTO 到 DO 的转换,然后应用服务接收 DO 进行业务处理。如果 DTO 与 DO 是一对多的关系,这时就需要进行 DO 数据重组。
- 用户接口层会完成 DO 和 DTO 的互转,完成微服务与前端应用数据交互及转换。Facade 服务会对多个 DO 对象进行组装,转换为 DTO 对象,向前端应用完成数据转换和传输。
- 前端应用主要是 VO 对象。展现层使用 VO 进行界面展示,通过用户接口层与应用层采用 DTO 对象进行数据交互。