代码规范性思考

表命名和设计

业务模块前缀；下划线分隔，体现业务含义；数据库字符集、字段名、类型、长度、默认值；一对一、一对多、多对多建表；注释清晰；良好的索引；

接口文档

swagger增强工具swagger-bootstrap-ui、Knife4j

通用出入参包装类

RestRequest<T>、RestResponse<T>

入参校验

@Validated注解、分组校验(如果文档严格，可使用不同BO，分组则用不上)，可以使用通用嵌套即接口来做分组。

通用BO

详情和删除、批量删除等可采用通用BO，如IdBO、BatchIdBO。同个业务的新增、修改接口字段无变化可使用Upsert。

代码分层架构

基本都是api、common、client、service、business

全局异常及断言

采用全局异常+断言公共类可避免大量if/else和return，提高代码简洁性

公共类

公共类需要规范、审查，并通知到开发人员

关联数据完整性校验

配置后产生关联的关联数据，在入参时与配置做对比，提系统安全和健壮性。

删除再插入还是区分新增、更新、删除

各有优缺点，个人偏向于后面这种，好处是大部分业务数据是逻辑删除，且业务配置逐渐稳定，一个简单的修改要重新生成所有数据得不偿失，此外还有个好处是更新可控制到字段级别粒度，通过对比新旧字段值来控制是否更新数据。有利于减少数据量和数据库交互次数。

用户信息网关统一赋值

在请求头中设置用户数据

领域模型之核心业务层以及VO、DTO

核心业务层理解不够，不作描述。VO好处在于接口文档更清晰和精细数据返回、DTO数据库交互返回，常常替代VO。

实体模型转换

建议使用MapStruct，自动生成转换器，类似手动赋值，无需反射，减少性能损耗

自定义sql还是在业务实现（持久层框架增强工具）

关联表多，可以拿到主体分页数据后再到业务层去查询关联数据赋值。

公共字段赋值方案

有些框架自带，如mybatis-plus。如果使用tk-mybatis这种，要自己到mybais拦截器中实现

出参文档

如果严格的化，每个接口返回定义一个VO或DTO

代码扫描

感觉Alibaba Java Coding Guidelines挺好

缓存

看业务，一般不经常变动的配置类数据容易做缓存

分布式锁

重要操作的接口加上

接口调试及自测

swagge增强UI中自带，都是不完整。复杂点用postman

联调

热部署插件如Jrebel，偶尔出现奇怪的代码异常报错问题