1 组件
业务组件、开源组件、中间件的使用和引入需要注意几个原则规范
1.1 组件规范
| 规范 |
说明 |
备注 |
| 单一职责 |
组件职责范围单一，不糅杂其他组件，过大适当拆分模块 |
例如：导入导出组件聚焦EXCEL处理，不揉杂定时任务、MQ等业务逻辑 |
| 依赖聚焦 |
组件的引用不散落在各个模块，最好只有一个地方依赖，不扩散不凌乱 |
|
| 插件化 |
组件支持插拔式，不耦合，有无都不影响主流程 |
MQ事件组件 |
| 开关式启用 |
支持配置是否启用组件 |
|
| 边界定位清晰 |
根据组件职能锚定工程中合适的位置，合理处理模块边界和防腐 |
例如：定时任务属于南向流量应与API同级，不能随便糅杂在领域层 应用层；ES属于北向流量，应该下沉到底层，不应该放在领域层 |
| 命名独有性 |
组件命名得有自己独有业务含义，避免与其他组件重名 |
|
| 包路径独有性 |
包路径需带有独有业务参与路径组成部分，避免与其他模块重复冲突 |
|
| 扫描路径独有性 |
扫描路径需带有独有业务参与路径组成部分，避免与其他模块重复冲突 |
csb-event-app模块扫描路径过大 |
1.2 组件例子
1.2.1 组件单一职责
| 示例 |
改前 |
改后 |
| 异步导入导出组件 |
所有逻辑都糅杂在sdk模块 |
调整后按需集成模块 |
2 代码
2.1 边界清晰
| 规范 |
说明 |
备注 |
| 关联组件边界 |
组件相关代码建议强关联组件所推荐模块位置，不建议跨模块，扩散，高内聚 |
|
| 单一职责 |
类的功能职责要单一，不能既有又有，各种逻辑混合侵染 |
|
|
|
|
2.2 事务规范
| 规范 |
说明 |
备注 |
| 从源头开启 |
事务注解需要在业务代码最开始的地方加上，其他地方不允许添加 |
基本是必须在业务应用层，不允许在核心层 |
| 不推荐手动开启事务 |
不推荐手动写代码单独开启事务 |
|
| 不推荐使用批处理提交 |
手动开启批处理session，批量提交事务，例如：批量插入 批量更新 |
实战证明比较慢 |
2.3 命名规范
| 规范 |
说明 |
备注 |
| 对外服务调用需要带上本项目标识 |
对外服务调用除了业务本身的命名之外建议带上当前项目的关键标识 |
app和data都有调用hub的服务，命名都是HubClient,集成聚合容易冲突，建议改成HubAppClient |
| 重叠功能需要带上本项目标识 |
多个项目有类似或者相同功能，需带上当前项目都关键标识 |
例如文件功能，app和data都有 |
| DTO类需要带上本项目标识和按需带上层级标识 |
对外相关的DTO避免与其他服务命名冲突，需要做区分 |
|
2.4 编写规范
| 规范 |
说明 |
备注 |
| rest接口url地址需带上本项目标识 |
url接口地址规范需按照/v1/项目标识/业务功能格式 |
避免重复冲突 |
| 两处及以上DTO类需要抽取到公共base模块 |
如果一个DTO类会被多个服务用到，不允许复制到各个服务，而是抽取到公共模块 |
|
| 公共枚举即使只有本服务使用也推荐放在公共base模块 |
所有服务使用都是这样，有可能会用到，对外传递，非私有内置逻辑都推荐放在公共base模块 |
|
| git提交需要带上版本 |
提交信息中必须包含：操作(feature/modify/fix),版本,详细信息(JIRA任务编号可以放在详细信息) |
|
|
|
|
|
|
|
作者：聂维 创建时间：2024-09-18 17:14
最后编辑：聂维 更新时间：2024-12-23 11:22
