代码规范性思考
表命名和设计
业务模块前缀；下划线分隔，体现业务含义；数据库字符集、字段名、类型、长度、默认值；一对一、一对多、多对多建表；注释清晰；良好的索引；
接口文档
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，偶尔出现奇怪的代码异常报错问题