发福利了,具体请前往官网!!!
DDD分层与传统三层区别
根据DDD领域驱动设计原则,对应的软件架构也需要做出相应的调整。 我们常用的三层架构模型划分为表现层,业务逻辑层,数据访问层等,在DDD
分层结构中既有联系又有区别, 个人认为主要有如下异同:
- 在架构设计上,在
DDD
分层结构中将传统三层架构的业务逻辑层拆解为应用层和领域层 其中Application划分为很薄的一层服务,非核心的逻辑放到此层去实现,核心的业务逻辑表现下沉到领域层去实现,凝练为更为精确的业务规则集合,通过领域对象去阐述说明。
;
- 在建模方式上,
DDD
分层的建模思维方式有别于传统三层 传统三层通常是以数据库为起点进行数据库分析设计,而DDD
则需要以业务领域模型为核心建模(即面向对象建模方式),更能体现对现实世界的抽象。 故在DDD分层凸显领域层的重要作用,领域层为系统的核心,包括所有的业务领域模型的抽象表达。 - 在职责划分上,基础设施层涵盖了2方面内容
- 持久化功能,其中原三层架构的数据访问层下沉到基础设施层的持久化机制实现
- 通用技术支持,一些公共通用技术支持也放到基础设施层去实现。
DDD分层详解
四层架构图
在该架构中,上层模块可以调用下层模块,反之不行。即
Interface
——>application
|domain
|infrastructure
application
——>domain
|infrastructure
domain
——>infrastructure
分层作用
分层 | 英文 | 描述 |
---|---|---|
表现层 | User Interface | 用户界面层,或者表现层,负责向用户显示解释用户命令 |
应用层 | Application Layer | 定义软件要完成的任务,并且指挥协调领域对象进行不同的操作。该层不包含业务领域知识。 |
领域层 | Domain Layer | 或称为模型层,系统的核心,负责表达业务概念,业务状态信息以及业务规则。即包含了该领域(问题域)所有复杂的业务知识抽象和规则定义。该层主要精力要放在领域对象分析上,可以从实体,值对象,聚合(聚合根),领域服务,领域事件,仓储,工厂等方面入手 |
基础设施层 | Infrastructure Layer | 主要有2方面内容,一是为领域模型提供持久化机制,当软件需要持久化能力时候才需要进行规划;一是对其他层提供通用的技术支持能力,如消息通信,通用工具,配置等的实现; |
领域对象
根据战术设计,关注的领域对象主要包括有
类型 | 英文 | 描述 |
---|---|---|
值对象 | value object | 无唯一标识的简单对象 |
实体 | entity | 充血的领域模型,有唯一标识 |
聚合(聚合根) | aggregate | 实体的聚合,拥有聚合根,可为某一个实体 |
领域服务 | service | 无法归类到某个具体领域模型的行为 |
领域事件 | event | 不常用 |
仓储 | repository | 持久化相关,与基础设施层关联 |
工厂 | factory | 负责复杂对象创建 |
模块 | module | 子模块引入,可以理解为子域划分 |
各层数据转换
- POJO(plain ordinary java object) :简单java对象,个人感觉POJO是最常见最多变的对象,是一个中间对象,也是我们最常打交道的对象。一个POJO持久化以后就是PO,直接用它传递、传递过程中就是DTO,直接用来对应表示层就是VO。(POJO、PO、DTO、VO都是处理流程中的名字,不是PO对应一个POJO,DTO对应一个POJO,VO对应一个POJO在有些情况下PO、DTO、VO是指同一个POJO)
- VO(View Object):视图对象,主要对应界面显示的数据对象。它的作用是把某个指定页面(或组件)的所有数据封装起来。如果是一个DTO对应一个VO,则DTO等价于VO;但是如果一个DTO对应多个VO,则展示层需要把VO转换为服务层对应方法所要求的DTO,传送给服务层,从而达到服务层与展示层解耦的效果。对于一个WEB页面,或者SWT、SWING的一个界面,用一个VO对象对应整个界面的值。
- BO(business object):业务对象,主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。比如一个简历,有教育经历、工作经历、社会关系等等。我们可以把教育经历对应一个PO,工作经历对应一个PO,社会关系对应一个PO。建立一个对应简历的BO对象处理简历,每个BO包含这些PO。这样处理业务逻辑时,我们就可以针对BO去处理。
- DTO(Data Transfer Object):数据传输对象,主要用于远程调用等需要大量传输对象的地方。比如我们一张表有100个字段,那么对应的PO就有100个属性。但是我们界面上只要显示10个字段,客户端用WEB service来获取数据,没有必要把整个PO对象传递到客户端,这时我们就可以用只有这10个属性的DTO来传递结果到客户端,这样也不会暴露服务端表结构.到达客户端以后,如果用这个对象来对应界面显示,那此时它的身份就转为VO。在这里,我泛指用于展示层与服务层之间的数据传输对象。
- DO(Domain Object):领域对象,就是从现实世界中抽象出来的有形或无形的业务实体。它用来接收数据库对应的实体,是一种抽象化的数据状态,介于数据库与业务逻辑之间。一般在业务逻辑层(Service)对数据库(SQL) 进行访问时,用于接收数据。xxxDO,xxx即为数据表名。另外,DO与Entity的不同点就是DO是与数据库存在着某种映射关系的Entity,总的来说DO是Entity的一种。
- PO(Persistent Object):持久化对象,它跟持久层(通常是关系型数据库)的数据结构形成一一对应的映射关系,如果持久层是关系型数据库,那么,数据表中的每个字段(或若干个)就对应PO的一个(或若干个)属性。最形象的理解就是一个PO就是数据库中的一条记录,好处是可以把一条记录作为一个对象处理,可以方便的转为其它对象。
DDD编码实践
代码结构描述
eg.
后端Java代码工程为例, 表现层
在此代码结构中表现为api层
,对外暴露接口的最上层
├─com.company.microservice
│ │
│ ├─apis API接口层
│ │ ├─model 视图模型,数据模型定义 vo/dto(大多数情況是一样的)
│ │ ├─assembler 装配器,实现模型转换eg. apiModel<=> domainModel
│ │ └─controller 控制器,对外提供(Restful)接口
│ │
│ ├─application 应用层
│ │ ├─service 应用服务,非核心服务
│ │ ├─task 任务定义,协调领域模型
│ │ └─*** others
│ │
│ ├─domain 领域层
│ │ ├─common 公共代码抽取,限于领域层有效
│ │ ├─events 领域事件
│ │ ├─model 领域模型
│ │ │ ├─dict 领域划分的模块,可理解为子域划分
│ │ │ │ ├─DictVo.java 领域值对象
│ │ │ │ ├─DictEntity.java 领域实体,充血的领域模型,如本身的CRUD操作在此处
│ │ │ │ ├─DictAgg.java 领域聚合,通常表现为实体的聚合,需要有聚合根
│ │ │ │ └─DictService.java 领域服务,不能归与上述模型,如分页条件查询等可写在此处
│ │ │ ├─xxx
│ │ │ │ ├─xxxEntity.java
│ │ │ │ ├─bbbAgg.java
│ │ │ │ └─cccAgg.java
│ │ ├─service 领域服务类,一些不能归属某个具体领域模型的行为
│ │ └─factory 工厂类,负责复杂领域对象创建,封装细节
│ │
│ ├─infrastructure 基础设施层
│ │ ├─persistent 持久化机制
│ │ │ ├─po 持久化对象
│ │ │ └─repository 仓储类,持久化接口&实现,可与ORM映射框架结合
│ │ ├─general 通用技术支持,向其他层输出通用服务
│ │ │ ├─config 配置类
│ │ │ ├─toolkit 工具类
│ │ │ └─common 基础公共模块等
│ │
│ └─resources
│ ├─statics 静态资源
│ ├─template 系统页面
│ └─application.yml 全局配置文件
其中在上述目录结构中,Domain层中为对module
进行划分,实际上默认该层只有一个模块,根据微服务划分可以进行增加模块来规范代码结构。
领域模型注入仓储类的问题
区别于传统的分层后,在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”)
@Component
public class ApplicationContextUtils implements ApplicationContextAware {
public static ApplicationContext appctx;
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
ApplicationContextUtil.appctx=applicationContext;
}
/**
* @return ApplicationContext
*/
public static ApplicationContext getApplicationContext() {
return appctx;
}
/**
* 获取对象
*
* @param name spring配置文件中配置的bean名或注解的名称
* @return 一个以所给名字注册的bean的实例
* @throws BeansException 抛出spring异常
*/
public static <T> T getBean(String name) throws BeansException {
return (T) appctx.getBean(name);
}
/**
* 获取类型为requiredType的对象
*
* @param clazz 需要获取的bean的类型
* @return 该类型的一个在ioc容器中的bean
* @throws BeansException 抛出spring异常
*/
public static <T> T getBean(Class<T> clazz) throws BeansException {
return appctx.getBean(clazz);
}
/**
* 如果ioc容器中包含一个与所给名称匹配的bean定义,则返回true否则返回false
*
* @param name ioc容器中注册的bean名称
* @return 存在返回true否则返回false
*/
public static boolean containsBean(String name) {
return appctx.containsBean(name);
}
}
考虑到代码结构简洁性,还可以封装一层仓储工厂,只用来获取相应的仓储Bean
。
/**
* 简化版的仓储工厂--用来统一获取仓储的实现Bean
*
* @author jockeys
* @date 2020/9/12
*/
public class RepoFactory {
/**
* 根据仓储接口类型获取对应实现且默认取值第一个
*
* @param tClass 具体目标类型
* @param <T> 仓储接口类型
* @return 如果不是指定实现,默认获得第一个实现Bean
*/
public static <T> T get(Class<? extends T> tClass) {
Map<String, ? extends T> map = ApplicationUtils.getApplicationContext().getBeansOfType(tClass);
Collection<? extends T> collection = map.values();
if (collection.isEmpty()) {
throw new PersistException("未找到仓储接口或其指定的实现:" + tClass.getSimpleName() );
}
return collection.stream().findFirst().get();
}
}
然后在领域模型中就可以直接调用该工厂方法来获取仓储接口的实现, 比如DictRepo
为定义的仓储接口,DictDao
为该接口的准实现类
//直接指定实现
DictRepo repo= RepoFactory.get(DictDao.class);
//不指定实现取Spring容器中默认注册第1位的Bean
DictRepo repo= RepoFactory.get(DictRepo.class);
一些个人思考…
上述经典四层架构,笔者更愿意理解为DDD在编码实现阶段的一个体现或应用。
补充一点:DDD除了在编码实践阶段,还体现在需求分析、设计阶段等过程,DDD推荐不割裂系统的需求和设计,我们这里可以合并称作系统建模过程
当然除了这个经典四层架构模型,DDD还有五层架构、六边形架构等,所以这里抛出一个问题,
项目按上述经典四层架构进行搭建,可以说是DDD架构实践么?
关于这个问题,笔者想引入一对哲学概念,哲学有言形式与内容,现象与本质等辩证关系(当然与本文可能也没啥太大关系啦);从这两个角度来阐述本人的观点:
- 形式与内容:经典四层架构是一个DDD实现的形式,相当于给我们提供了一个框框来让我们自己去实现;在这个框框里面我们怎么实现是自由发挥的,但也是有约束的,这个约束体现在DDD对每一层的作用的约定,如每个层约定做了什么功能,充当什么角色等。尤其是对Domain层的约定,才是最重要的。那么我们按照哲学辩证的套话来说,形式上满足了DDD架构,但这应该是片面的,具体还要看内容,即具体实现是怎样的。
- 现象与本质:接着上述观点,如果要看实现,就要具体分析一下现象与本质嘞。上面笔者也有提到,DDD除了四层经典架构,还有五层架构(包括其演化的多层架构)、六边形架构等也都是DDD提供的架构模型(形式),那这些都可以理解DDD架构模式的外显形式,那么又有哪些共性呢?可自行查询,本文直接给结论,即它们都有Domain层,Domain层,Domain层(重要的事情说三遍~~,该结论DDD作者译著有写到…),所以不管架构模式怎么演化,Domain是核心不能变。 那么如上分析,我们在回到这个问题,我们是不是可以给出一个这样的答案: 形式上符合DDD架构,具体是不是DDD的架构实践,本质上还要看
- (1)项目是否包括有Domain层;
- (2)Domain层是否满足DDD战术篇的要求(或者可暂时简单理解为充血模型吧)
题外话:Spring与DDD
- Spring框架中,Spring为我们提供了
@Service
@Repository
等注解,为我们分离行为和行为(注册为Bean)和属性(数据模型),同时通过@Autowired
在合适地方进行注入行为,因为行为被注册为Spring容器中的Bean后,减少了频繁创建行为的开销,只有属性的数据模型作为数据的载体来传递数据。提供很大的便捷性。但也阻碍了我们应用DDD编码实践, Spring框架主张分离,DDD思想主张合并,我们在Spring框架中使用DDD则需要在其基础上进行一些权衡取舍,即 如何将注册为Bean的行为穿插到原有的贫血模型中来构建充血模型是我们要解决的问题 - 关于这个问题,笔者使用了Spring框架提供的获取容器内已经注册的Bean接口,直接调用接口,在有属性的领域模型中来获取行为;主要还是体现融入领域模型中的部分Service获取仓储接口来实现持久化过程。
📢文章下方有交流学习区!一起学习进步!也可以前往官网,加入官方微信交流群💪💪💪
📢首发CSDN博客,创作不易,如果觉得文章不错,可以点赞👍收藏📁评论📒
📢你的支持和鼓励是我创作的动力❗❗❗