DDD分层架构、洋葱架构、六边形架构

本文最后更新于:2022年8月8日 上午

一、DDD分层架构

DDD分层架构中有很重要的依赖原则:每层只能与位于下方的层发生耦合,类似于网络的7层或TCP/IP的4层模型架构,每一层各司其职,并且只关心向下一层的实现,而不会出现各层耦合。

DDD分层架构中包含四层:从上到下分别是用户接口层,应用层,领域层和基础层。

二、洋葱架构

2008年Jeffrey Palermo已经提出了具有分层思想的洋葱架构,如下图,同心圆代表软件的不同部分,从里向外依次是领域模型,领域服务,应用服务和外层的基础设施和用户终端。

洋葱架构根据依赖原则,定义了各层的依赖关系,越往里依赖程度越低,代码级别越高,越是核心能力。外圆代码依赖只能指向内圆,内圆不需要知道外圆的情况,这种架构也是典型的分层架构,和DDD分层架构一样,都体现了高内聚,低耦合的设计特性。洋葱架构也常作为指导微服务设计的重要架构之一。

三、六边形架构

2005年Alistair Cockburn提出了六边形架构,在这个架构中,将应用分为内六边形和外六边形两层,内六边形实现应用的核心业务逻辑。外六边形完成外部应用,基础资源等的交互和访问,对于与不同的外部系统交互,由外六边形的适配器负责协议转换,保证内六边形业务逻辑的干净。

这种架构也是典型的分层架构,和DDD分层架构一样,都体现了高内聚,低耦合的设计特性。六边形也常作为指导微服务设计的重要架构之一。

四、DDD分层协作

DDD各层的主要职责和怎么分工协作如下图:

PO(数据持久化对象):与数据库字段映射的数据载体

DO(领域对象):领域模型核心业务对象的载体,包括实体和值对象

DTO(数据传输对象):用于前端和微服务交互的数据传输载体

用户接口层:主要有facade接口,Assembler转换器

  • 微服务面向不同前端时,需要展示的数据可能不同,此时由于需要保持领域核心业务逻辑的稳定,不可能去定制开发各种领域服务和应用服务编排。因此,为避免暴露服务端业务逻辑,防止非必需的字段数据外泄
    ,同时保证领域逻辑的干净,用户接口层的facade接口和Assembler转换器就发挥作用了。
  • facade接口用于封装应用服务,适配不同前端需要的字段,提供不同要求的服务接口适配。Assembler根据不同前端的数据请求,完成DTO和领域DO对象的组装,转换,完成数据适配。

应用层:

  • 应用层连接用户接口层和领域层,主要协调领域层,面向用例和业务流程,协调多个聚合完成服务的组合和编排,在这一层不实现任何业务逻辑,只是很薄的一层

  • 如何判定一个东西是否属于业务逻辑?

    很简单,只需设想你和产品聊这个事情时,需不需要把这部分信息输入给它?比如接口调用的处理,数据的转换,是否加了缓存等等都不属于产品关心的东西,所以不算是业务逻辑

  • 应用层编排成应用服务后,被接口层facade封装,完成接口和数据适配后,以粗粒度向API网关发布服务

  • 应用层还负责事件的订阅和发布,以及与其他外部服务的交互,事件的具体实现则在领域层

领域层:

  • 领域层位于应用层之下,是领域模型的核心,主要实现领域模型的核心业务逻辑,体现领域模型的业务能力
  • 领域层关注实现领域对象的充血模型和聚合本身的原子业务逻辑,至于用户操作和业务流程,则交给应用层去编排。这样设计可以保证领域模型不容易受外部需求变化的影响,保证领域模型的稳定
  • 跨多个聚合的领域逻辑在领域层实现,由领域服务组织和协调多聚合的多实体,实现原子业务逻辑

基础层:

  • 基础层贯穿了DDD所有层,包括第三方工具,API网关,消息中间件,分布式事务,消息最终一致性能力,数据库,缓存能能力的提供。
  • 基础层有仓储模式的代码逻辑,通过仓储接口和仓储实现,解耦领域层和基础层,保证领域核心业务逻辑的干净,降低DB资源变化给领域层带来的影响,这部分内容,请见下回分解。

References


DDD分层架构、洋葱架构、六边形架构
https://baymax55.github.io/2022/09/13/java/DDD分层架构、洋葱架构、六边形架构/
作者
baymax55
发布于
2022年9月13日
许可协议