代码
概述
修改代码架构, 使用Mapstruct和Lombok解决setter(),getter()以及查询结果到dto的转换
[Mapstruct文档](http://https://mapstruct.org/documentation/1.5/reference/html/#Preface "Mapstruct文档") [Lombok简单介绍](https://cloud.tencent.com/developer/article/1698734 "Lombok简单介绍")
结构如下:
一个控制层可以依赖多个应用
一个应用层只有一个仓库和多个服务
仓库由一个或多个DAO组成
每一层的方法都需要描述输入输出信息
目录结构
root
|
|____controler 控制层
|
|____types 类型
| |
| |____dto 请求或响应数据对象
| |
| |____cmd 命令出查询外的请求
| |
| |____query 查询请求
| |
| |____event 事件
|
|____exception 异常
| |
| |____handle 异常处理
|
|____application 应用层
| |
| |____assembler 转换层
|
|____domain 领域层
| |
| |____entity 实体
| |
| |____vo 值对象
|
|____facade 装饰层
|
|____service 服务层
|
|____repository 仓库层
|
|____convert 转换层
|
|____mapper/dao 接口层
|
|____do 数据对象
控制层
路由
根据调用方的的不同使用不同的路径
backend/front/mini/app
加上不同的版本号
1/1_1/1_0_0 表示不同颗粒度
再加上rest风格路径, 如图
总体代码
控制层只存在将请求参数转换成命令和调用应用方法的代码, 如图
把数据的校验通过值对象的构造函数实现, 凡是使用到该值对象的地方输入的值都符合要求, 且只需要修改该值对象的校验条件就能修改所有使用到的地方
注释
类注释应该标注, 服务的根对象(如用户控制的根对象是用户, 用户的部门, 角色都是补充信息的字段)
在方法的注释中应该描述输入和输出的数据, 接口的功能
输入输出
控制层应该输入DTO, 输出DTO(特指请求参数, 与返回参数), 返回DTO应该包含三点信息(给浏览器的code, 给前端的code和msg, 给用户的msg)
与应用的关系
一个控制可以依赖多个应用, 通过不同的应用实现不同的功能(根据应用依赖的仓库决定, 仓库能查询的范围决定了应用功能的范围)
控制层不在包含业务逻辑, 业务逻辑下沉到应用层, 控制层通过依赖哪些应用来控制接口逻辑的变更
输入校验
不在dto上使用注释控制输入数据限制, 而是在值对象的构造方法中判断
创建新的DTO时不需要考虑给字段增加哪些校验注解
应用层
总体代码
应用层只包含流程代码, 不应出现业务代码(具体逻辑,控制语句,循环语句)
具体的业务代码由服务层和实体完成
应用层应该明确职责, 根据依赖的仓库能查询到的数据区分
注释
类注释上应该描述该应用提供的功能
在方法的注释中描述输入和输出的数据, 接口的功能
输入输出
应用层接受命令类型输入,如:command,query,event, 输出DTO类型
与仓库的关系
一个应用使用一个仓库, 一个仓库可以依赖一个或多个DAO, cache等
服务层
总体代码
具体的业务逻辑,单个服务的功能应该要单一,如新增用户时对用户名的唯一校验需要一个服务, 可以使前后台共用一个服务校验
需要提前结束时抛出对应的错误, 在配置全局异常处理
注释
类注释表明该类提供的服务范围,如图
方法注释表明输入和输入, 简单介绍逻辑, 如图
与仓库的关系
服务不允许依赖仓库, 通过方法传参的形式传入仓库调用仓库方法, 如图
调用方可以通过传入不同的仓库实现查询不同的数据, 而不是在该服务内部控制
与其他服务的关系
允许服务层之间相互依赖,
仓库层
总体代码
不应出现业务逻辑
注意点
更新聚合时会导致全量更新, 以后可以通过快照实现
注释
在方法的注释中应该描述输入和输出的数据, 接口的功能
与DAO的关系
依赖一个或多个DAO, 只依赖应用或服务需要用到的DAO
包括redis,mogodb等
DAO层
总体代码
原来的mapper层前后台所使用的sql应该独立避免,逻辑混乱
注释
在方法的注释中应该描述输入和输出的数据, 接口的功能
实体与仓库的创建
实体
区分实体与值对象的关键在于是否有状态
实体必须包含主键
主键接口
实体接口
聚合接口
仓库
仓库接口
SQL
所有列表SQL都需要倒序