mirror of https://gitee.com/stylefeng/roses
更新readme
fengshuonan
parent
9c95a9a768
commit
64eccb04d4
166
README.md
166
README.md
|
|
@ -1,131 +1,53 @@
|
|||
## Roses核心包
|
||||
<p align="center">
|
||||
<img src="https://images.gitee.com/uploads/images/2019/0112/222304_562302ff_551203.png" width="300">
|
||||
<br>
|
||||
<br>
|
||||
<p align="center">
|
||||
Roses基于Spring Boot 2，是<a target="_blank" href="https://gitee.com/stylefeng/guns">开源项目Guns</a>的核心支撑层，亦可用于任何java项目支撑内核。
|
||||
<br>
|
||||
<br>
|
||||
<span>
|
||||
<span>
|
||||
Guns官方交流群：254550081(满) 684163663(满) 207434260(满)(三个群已满，扫下方二维码加官方微信群)
|
||||
</span>
|
||||
</span>
|
||||
<br>
|
||||
<br>
|
||||
<a href="http://spring.io/projects/spring-boot">
|
||||
<img src="https://img.shields.io/badge/spring--boot-2.3.5-green.svg" alt="spring-boot">
|
||||
</a>
|
||||
<a href="http://mp.baomidou.com">
|
||||
<img src="https://img.shields.io/badge/mybatis--plus-3.4.0-blue.svg" alt="mybatis-plus">
|
||||
</a>
|
||||
<a href="https://www.hutool.cn/">
|
||||
<img src="https://img.shields.io/badge/hutool-5.4.4-blue.svg" alt="hutool">
|
||||
</a>
|
||||
</p>
|
||||
</p>
|
||||
|
||||
基于《Java开发手册（嵩山版）》
|
||||
-----------------------------------------------------------------------------------------------
|
||||
|
||||
### 规则1 模块的分类（a类，d类，o类，s类，p类）
|
||||
### 更新说明
|
||||
|
||||
> a类排名第一，Advanced，为全模块的规则，本公司所有的代码都需要遵守的规则，包含枚举，异常，基础类等
|
||||
目前Roses已全面升级，整体模块化重构，整体功能分为4类，`规则类模块(R)`、`开发工具模块(D)`、`运维类模块(O)`、`业务类模块(S)`
|
||||
|
||||
> d类排名第二，Development，给开发人员用的快速开发工具，方便快速开发，例如日志，邮件，短信，缓存等
|
||||
### 配套手册
|
||||
|
||||
> o类排名第三，Operations，偏运维类的封装，例如监控，调用链记录，内网转发模块
|
||||
[https://doc.stylefeng.cn/contents/roses_kernel/](https://doc.stylefeng.cn/contents/roses_kernel/)
|
||||
|
||||
> s类排名第四，Service，偏应用功能的封装，例如用户管理，角色管理，公司管理，每个模块是一个独立的业务
|
||||
### 使用方式
|
||||
|
||||
> p类排名第五，Pattern，设计模式或业务解决方案，例如高并发的解决方案，海量数据存储方案等
|
||||
|
||||
### 规则2 模块的建设标准
|
||||
|
||||
> 2.1 模块建立的基本思想是封装重用的代码，提高开发效率
|
||||
|
||||
> 2.2 由团队核心成员评估批准后进行模块的编写，模块的编写要遵守第3条规定
|
||||
|
||||
### 规则3 模块设计思想
|
||||
|
||||
> 3.1 每个模块内部分三类子模块
|
||||
|
||||
分别是api、sdk、business，api为对其他模块暴露的接口，sdk是对核心功能的封装，business是带业务逻辑的封装
|
||||
|
||||
以短信模块kernel-d-sms为例，sms-api模块是接口模块，是短信功能提供的所有接口。
|
||||
|
||||
sms-sdk-aliyun模块是阿里云短信的sdk封装。
|
||||
|
||||
sms-sdk-tencent模块是腾讯云短信的sdk封装。
|
||||
|
||||
sms-business-validation模块是带短信验证功能（业务）的模块。
|
||||
|
||||
api、sdk、business为三类模块，不是三个，一般api模块仅一个，sdk和business类模块可以无限拓展。
|
||||
|
||||
> 3.2 依赖接口不依赖实现
|
||||
|
||||
模块与模块之间的调用，通过api模块来调用（例如sms-api），而不直接依赖他的实现（sms-sdk或sms-business），具体的实现由business模块决定或者由具体项目决定。
|
||||
|
||||
> 3.3 每个模块要详细编写readme
|
||||
|
||||
每个kernel模块要编写对应的readme文档
|
||||
|
||||
每个kernel的子模块也要写清楚readme文档
|
||||
|
||||
> 3.4 所有api的实现都装入spring容器中，使用api时通过@Resource注入api
|
||||
|
||||
同一个项目，一个api的实现可以有两个，需要通过@Resource(name = "xxx")指定资源的名字。
|
||||
|
||||
### 规则4 模块中任何类均可拓展
|
||||
|
||||
利用@Primary注解来替换已经装载的spring容器中的bean
|
||||
|
||||
## 规则5 每个模块要有一个常量类
|
||||
|
||||
常量类用来存放模块名称和异常枚举的步进值，如果本模块异常较多，可以存放多个步进值
|
||||
|
||||
```java
|
||||
public interface RuleConstants {
|
||||
|
||||
/**
|
||||
* 规则模块的名称
|
||||
*/
|
||||
String RULE_MODULE_NAME = "kernel-a-rule";
|
||||
|
||||
/**
|
||||
* 异常枚举的步进值
|
||||
*/
|
||||
String RULE_EXCEPTION_STEP_CODE = "00";
|
||||
|
||||
}
|
||||
```
|
||||
# 安装到本地maven仓库
|
||||
mvn clean install -Dmaven.test.skip=true
|
||||
```
|
||||
|
||||
## 规则6 每个模块要有一个异常类
|
||||
|
||||
异常类要集成ServiceException
|
||||
|
||||
```java
|
||||
public class DaoException extends ServiceException {
|
||||
|
||||
public DaoException(AbstractExceptionEnum exception) {
|
||||
super(DbConstants.DB_MODULE_NAME, exception);
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
## 规则7 强依赖
|
||||
|
||||
项目基于spring boot架构，所以对spring boot强依赖，另外对hutool工具类，lombok，fastjson强依赖，其他框架不强依赖
|
||||
|
||||
## 规则8 expander包是对配置表的拓展
|
||||
|
||||
kernel-d-config模块只负责对系统配置的初始化，新增，删除等操作，不进行对某个具体配置的维护，各个模块需要配置拓展属性时，在各个模块的api模块建立expander包维护
|
||||
|
||||
## 规则9 business可以依赖sdk层，sdk层可依赖api层，反之不行
|
||||
|
||||
## 规则10 高模块可依赖低模块的api，反之不行
|
||||
|
||||
s类的api模块可以依赖d类的api，反之不行，防止出现互相依赖（循环依赖）的情况
|
||||
|
||||
## 规则11 Bean的装配，尽量在类的构造函数，不要在类的内部用@Resource或者@Autowired
|
||||
|
||||
构造函数装配更灵活，如果直接用@Resource则会交给spring去装配，spring会去找到容器中的相关bean，不如手动的灵活
|
||||
|
||||
多出现在装配的是接口的情况，如果接口有多个实现，很明显用构造函数去装配更合适
|
||||
|
||||
## 规则12 pojo的分包结构
|
||||
|
||||
pojo下可以分为request（控制器层请求参数的封装），response（控制器层响应参数的封装），param（其他类下参数的封装）
|
||||
|
||||
其中request包下的类以Request结尾，response包下的类以Response结尾，param包下的类以Param结尾
|
||||
|
||||
request包下的类一般会加上参数校验注解，参数校验用的hibernate validator注解
|
||||
|
||||
一般情况，直接用实体返回，减少一些pojo的书写，复杂的返回对象还是要单独封装pojo
|
||||
|
||||
## 规则13 表的设计
|
||||
|
||||
表名不要用缩写，用全拼单词
|
||||
|
||||
排序字段用decimal带两位小数点，这样往里边插入数据的时候，不用改别人的排序，就可以通过小数来插入了，如果两位不够用的时候，还可以扩充为3位等等
|
||||
|
||||
表设计中，不要用mysql的关键字作为字段和表名
|
||||
|
||||
## 规则14 pom中的注释要写清楚，为什么引用这个模块写到每个依赖上边
|
||||
|
||||
## 规则15 像小白一样思考，像专家一样行动
|
||||
### 扫码关注官方公众号和官方微信群
|
||||
<table>
|
||||
<tr>
|
||||
<td>官方公众号</td>
|
||||
<td><img src="https://images.gitee.com/uploads/images/2019/0415/104911_9bc924a5_551203.png" width="120"/></td>
|
||||
<td>扫码邀请入群</td>
|
||||
<td><img src="https://images.gitee.com/uploads/images/2019/0419/103622_d6e9fa5d_551203.png" width="120"/></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
|
|
|||
Loading…
Reference in New Issue