简介
项目骨架和代码生成均采用ballcat提供的代码生成器，具体部署和使用方式参见->https://docs.ballcat.org/codegen/
在线网址
http://codegen.zhanghongbin.xyz
模版
在代码生成器规范下分别制定了三个模版：
单模块项目规范
目录结构
* ├──├── Readme.md
* ├── main // 单体项目
* │ ├──java // java文件目录,忽略顶层包结构
* │ │ ├──config // 存放项目的配置文件，如Spring配置、数据库配置等
* │ │ ├──constant // 存放项目中使用到的常量信息，如枚举类型、常量类等。
* │ │ ├──controller // 存放控制器类，负责接收请求并调用相应的服务进行处理。
* │ │ ├──domain // 存放实体类。
* │ │ │ ├──dto // 存放Dto实体类。
* │ │ │ ├──entity // 存放Entity实体类。
* │ │ │ ├──vo // 存放Vo实体类。
* │ │ ├──job // 存放定时任务相关的类，用于定时执行特定的任务。
* │ │ ├──mapper // 存放访问数据层的接口文件，用于实现数据库操作。
* │ │ ├──service // 存放服务层相关的类，负责实现业务逻辑。
* │ │ │ ├──impl // 存放服务层接口的具体实现类。
* │ │ ├──util // 存放工具类，包含项目中通用的工具方法。
* │ ├──resource // 资源目录文件目录。
* │ │ ├──mapper // 存放MyBatis等持久层框架的映射文件，描述数据库表与Java对象之间的映射关系。
* ├── test // 单元测试目录Rule 1. controller 编写规则
- Cntroller文件中只能引用Service文件，不可引用任何Mapper文件
- Controller文件中只处理参数校验、实体封装和转化、Service方法调用、异常捕捉、日志记录以及权限控制，不可参与其他业务逻辑处理
Rule 2. service 编写规则
- Service文件中只能引用自己的Mapper文件和其他Service文件，不可引用其他的Mapper文件，且Service文件中不可进行循环依赖
- Service文件中主要进行业务逻辑处理、事务管理、异常捕捉以及Service和Mapper方法调用等
- Service文件处理异常时，不可在接口方法上面直接throws，但是可以在方法内部对异常进行throw
Rule 3. 实体类编写规则
- Controller：入参和出参的实体类都放在 domain --> vo 文件夹中
- 入参，其中新增、修改和删除方法的实体类使用Command结尾，查询使用Query结尾，也可以使用普通入参，但是最多可以有5个参数，超过5个必须定义实体类。
- 出参，使用Result结尾，多于两个参数，必须定义实体类。如果底层的出参是Entity或Dto，且都能满足前端需要，可直接把Entity或Dto作为出参。
- Service：
- 入参，可以用Vo、Dto、普通入参，其中Dto实体类放在 domain --> dto 文件夹中，文件结尾都用 Dto，同样普通入参超过5个必须定义实体类。
- 出参，可以用Dto，Entity，如果Entity文件包含返回结果的所有字段，才可用Entity文件进行返回，其余情况需要定义Dto实体类。
- Mapper：
- 入参，可以用Entity、Dto、Vo、Map、普通参数，其中Entity实体类放在 domain --> entity 文件夹中，文件结尾都用 Entity。可结合实际情况选择入参类型，但尽量使用已存在的实体，不建议再创建新的实体类。
- 出参，可以用Entity，Dto，如果单表返回可用Entity，多表联合返回只能使用Dto。
Rule4. 环境配置规则
| 名称 | 环境文件 | 描述 |
|---|---|---|
| 主环境 | application.yml | 为数据库，redis基础配置等，在实际开发中还可以增加其它内容 |
| 开发环境 | application-dev.yml | 开发环境配置 |
| 测试环境 | application-test.yml | 测试环境配置 |
| 修复环境 | application-fix.yml | 修复环境配置 |
| 生产环境 | application-prod.yml | 生产环境配置 |
xml
<version>${revision}</version>
<profiles>
<profile>
<id>dev</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<revision>1.0.0-SNAPSHOT</revision>
<profiles.active>dev</profiles.active>
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<revision>1.0.0-alpha</revision>
<profiles.active>test</profiles.active>
</properties>
</profile>
<profile>
<id>fix</id>
<properties>
<revision>1.0.1-SNAPSHOT</revision>
<profiles.active>fix</profiles.active>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<revision>1.0.0</revision>
<profiles.active>prod</profiles.active>
</properties>
</profile>
</profiles>多模块项目规范
目录结构
* ├──├── Readme.md // 项目介绍
* ├── 项目名称 // 多模块项目
* │ ├──项目名称-moudle-application // 启动和配置模块
* │ │ └── AdminApplication // 项目启动类
* │ │ └── resources // 项目配置文件
* │ ├──项目名称-moudle-模块名称 // 业务模块
* │ │ ├──项目名称-moudle-模块名称-api // 业务模块接口
* │ │ ├──项目名称-moudle-模块名称-biz // 业务模块具体实现
* │ ├──项目名称-moudle-common // 公共模块Rule 1. 模块规则
- 启动模块(后缀为application)：包含项目的启动类和配置文件。
- 业务模块(后缀业务名称)：包括api和biz结尾的子模块
- 公共模块(后缀为common)：公共模块，存放其他模块共用的资源或配置信息。
Rule 2.业务模块规则
有两个模块组成：api结尾的子模块和biz结尾的子模块。
api结尾的模块主要是为其它模块提供业务支持，所有接口都需要放到api包下，接口名称要以Api结尾，biz模块需要实现api模块里声明的接口，其它模块在使用此模块时，需要依赖api模块。
biz结尾的模块为实际的业务核心模块，如果存在api接口需要建立api目录并实现相关接口，实现类要以ApiImpl结尾为注解@Service