防腐层规范

引入防腐层的目的

防腐层这个名词来源于系统集成的场景，一般是为了隔离两个系统之间的变化，防止一个系统的微小变化会影响到另外一个系统。还一个场景，两个系统使用的技术栈不一致，所以需要有一层代理来做兼容。

 

防腐层现状

现有防腐层独立一个仓库是由历史原因促成的，目前业务扩大，人员扩展，项目组也开始拆分，这么多组和业务共用一个仓库的防腐层已经不合适了，各种问题已经显现，如下

1. 发版依赖过多慢慢慢，其他不相关模块也进行发版  

2. 多端同时使用一个模块，兼容改动有风险，变更要同时上线

3. mock层，mock数据大家相互使用

    

防腐层拆分

各个业务自己维护防腐层，需要将server-adapter中使用代码移入自己业务中。

拆分基本方案（建议），各端跟进实际情况具体执行

1. 业务内多个模块（appkey）共用的防腐层，可以单独申请GIT仓库，把相关代码移入

2. 业务内单个模块（appkey）使用的防腐层，可以移动到工程内部，创建新的子moulde或者新的package

新功能请不要在原防腐层开发，请在业务内完成。

 

代码规范建议（M-must,R-recommend）

1.防腐层之间不能进行调用（M）

2.防腐层不允许有大量的业务逻辑，业务逻辑部分上提到调用端（M）

3.一个防腐层对应一个api（R）

4.各端调用其他端必须使用防腐层进行调用（R）

注意

防腐层modules只能引入本项目的api依赖，其他依赖不可引入。

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

背景

防腐层职责：

• 异常降级：对RPC调用可能抛出的异常捕获，降级处理（输出异常日志、返回empty结果 / 抛出业务异常errorcode）；

• 超时/重试：RPC接口的超时、重试 统一管理

• 数据校验：对返回值的正确性、边界值进行校验，进行数据的基本防御、业务代码边界值的解耦；

• 接口防腐：转换成Vo值对象，避免下游接口的修改 导致 自身系统的修改；

防腐层目的

• 代码复用：RPC的调用场景 差异化小，proxy层复用，提高开发效率；

• 提供便利性：调用方可以直接调用，对RPC结果可以直接使用，不需要考虑NPE（结果为空）、RPC异常等情况；