传统的三层架构实际上我们能够很明显的发现,我们的数据库将会做为架构起点,我们会从数据库层面开始分析以及设计,但是我们的DDD他的重点其实不在数据库,而是在领域模型,我们会将领域模型做为我们的分析基点,向上进行衍生。进而进行分层设计。
四层架构设计是松散分层架构,其上层可以直接访问下面的任何一层:UserIntefce可以直接访问Domain,任何一层可以直接访问Infrastructure层。相反的,严格分层架构,其上层只能访问与之仅连的一层,不可以跨层访问。
├─com.yangsx95
│ │
│ ├─apis API接口层
│ │ ├─model 视图模型,数据模型定义 vo/dto(大多数情況是一样的)
│ │ ├─assembler 装配器,实现模型转换 apiModel => domainModel (在Java项目里可以使用MapStruct为此层提供功能)
│ │ └─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 全局配置文件