...
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, 输出DTO(特指请求参数, 与返回参数), 返回DTO应该包含三点信息(给浏览器的code, 给前端的code和msg, 给用户的msg)
与应用的关系
一个控制可以依赖多个应用, 通过不同的应用实现不同的功能(根据应用依赖的仓库决定, 仓库能查询的范围决定了应用功能的范围)
控制层不在包含业务逻辑, 业务逻辑下沉到应用层, 控制层通过依赖哪些应用来控制接口逻辑的变更
输入校验
不在dto上使用注释控制输入数据限制, 而是在值对象的构造方法中判断
...