DDD领域驱动设计：四层架构应用_四层架构和三层架构的区别

作者：菜鸟追梦旅行 | 2024-04-07 00:18:38

踩

四层架构和三层架构的区别

文章目录

前言
一、DDD四层与传统三层区别
二、四层架构详解
- 1.分层作用
- 2.领域对象
三、编码实践
- 1.代码结构
五、扩展
四、常见问题
- 1.领域模型（充血模型）注入问题
结尾

前言

分层架构是运用最为广泛的一种架构模式，几乎每个软件系统都需要通过分层来隔离不同的关注点，以应对不同需求的变化，并且使得这种变化可以独立进行。对于分层架构来说，层次越往上其抽象层次就越面向业务和用户，层次越往下其抽象层次就越面向技术和设备。

一、DDD四层与传统三层区别

我们常用的三层架构模型划分为表现层，业务逻辑层，数据访问层等，在DDD分层结构中既有联系又有区别，个人认为主要有如下异同：

在架构设计上，在DDD分层结构中将传统三层架构的业务逻辑层拆解为应用层和领域层

其中Application划分为很薄的一层服务，非核心的逻辑放到此层去实现，核心的业务逻辑表现下沉到领域层去实现，凝练为更为精确的业务规则集合，通过领域对象去阐述说明。
在这里插入图片描述

在建模方式上，DDD分层的建模思维方式有别于传统三层：

传统三层通常是以数据库为起点进行数据库分析设计，而DDD则需要以业务领域模型为核心建模（即面向对象建模方式），更能体现对现实世界的抽象。

故在DDD分层凸显领域层的重要作用，领域层为系统的核心，包括所有的业务领域模型的抽象表达。

在职责划分上，基础设施层涵盖两方面内容：

持久化功能，其中原三层架构的数据访问层下沉到基础设施层的持久化机制实现

通用技术支持，一些公共通用技术支持也放到基础设施层去实现。

二、四层架构详解

在这里插入图片描述

1.分层作用

分层	英文	描述
表现层	User Interface	用户界面层，或者表现层，负责向用户显示解释用户命令
应用层	Application Layer	定义软件要完成的任务，并且指挥协调领域对象进行不同的操作。该层不包含业务领域知识。
领域层	Domain Layer	也可称为模型层，系统的核心，负责表达业务概念，业务状态信息以及业务规则。即包含了该领域（问题域）所有复杂的业务知识抽象和规则定义。该层主要精力要放在领域对象分析上，可以从实体，值对象，聚合（聚合根），领域服务，领域事件，仓储，工厂等方面入手
基础设施层	Infrastructure Layer	主要有2方面内容，一是为领域模型提供持久化机制，当软件需要持久化能力时候才需要进行规划；一是对其他层提供通用的技术支持能力，如消息通信，通用工具，配置等的实现；

2.领域对象

类型	英文	描述
值对象	value object	当一个对象用于对事务进行描述而没有唯一标识时，它被称作值对象
实体	entity	当一个对象由其标识（而不是属性）区分时，这种对象称为实体
聚合（聚合根）	aggregate	一组相关对象的集合，作为一个整体被外界访问，聚合根（Aggregate Root）是这个聚合的根节点
领域服务	service	领域中的服务表示一个无状态的操作，用于实现特定于某个领域的任务，当某个操作不适合放在聚合和值对象时，最好的方式是使用领域服务
应用服务	application	应用服务是领域模型的直接客户，应用服务负责用例流的任务协调，每个用例流对应了一个服务方法
仓储	repository	仓储作为业务与数据的隔离层，屏蔽底层数据表细节，同时完成PO与DO的转化
工厂	factory	将创建复杂对象和聚合的职责分配给一个单独的对象，该对象本身并不承担领域模型中的职责

三、编码实践

1.代码结构

├─com.ddd
│    │ 
│    ├─interfaces   API接口层
│    │    ├─dto     视图模型,数据模型定义 vo/dto（大多数情況是一样的）
│    │    └─controller   控制器，对外提供（Restful）接口
│    │ 
│    ├─application   应用层
│    │    ├─service  应用服务，非核心服务 
│    │    └─***      others
│    │ 
│    ├─domain   领域层
│    │    ├─entity        领域实体、聚合根，充血的领域模型 
│    │    ├─valueobject        领域值对象       
│    │    └─service      领域服务类，一些不能归属某个具体领域模型的行为
│    │ 
│    ├─infrastructure  基础设施层
│    │    ├─po           持久化对象 
│    │    ├─repository   仓储类，持久化接口&实现，可与ORM映射框架结合
│    │    ├─dao         数据访问对象 
│    │    ├─client       feign等调用客户端 
└─   └─   └─factory      工厂类，负责复杂领域对象创建，封装细节

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

五、扩展

在这里插入图片描述

为什么要进行依赖倒置？

DDD四层架构是松散分层架构
分层架构原则：底层不能依赖高层的功能，即下层对上层无感知，故采用依赖倒置原则（面向接口编程），基础设施层负责repository的实现，repository接口定义在需求调用的层

四、常见问题

1.领域模型（充血模型）注入问题

区别于传统的分层后，在domain中更多关注业务逻辑，考虑到要与spring框架集成，需要注意一个领域模型中注入的问题

在传统分层中，controller，service，repo均注册为spring管理的bean，但是在domain层中，service一部分的业务逻辑划分到了具体的领域对象中去实现了，显然这些对象却不能注册为单例bean，因此在此处不能沿用与原来分层结构中service层中通过@Autowired or @Resource等注入接口

关于这个问题，此处建议使用ApplicationContext实现

即通过一个工具类 ApplicationContextUtils 实现 ApplicationContextAware获取bean的方法，即 getBean()方法，然后我们就可以在我们的领域模型中直接应用该工具类来获取Spring托管的singleton对象，xxxRepo=ApplicationContextUtils.getBean(“xxxRepository”)

结尾

感谢大家的耐心阅读，如有建议请私信或评论留言。
如有收获，劳烦支持，关注、点赞、评论、收藏均可，博主会经常更新，与大家共同进步

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/菜鸟追梦旅行/article/detail/375243