![]()
01 1、什么是复杂度
软件设计的核心在于降低复杂性。--《软件设计的哲学》 业界对于复杂度并没有统一的定义，斯坦福教授John Ousterhout从认知负担和工作量方面给出了一个复杂度量公式
![]()
子模块的复杂度cp乘以该模块对应的开发时间权重值tp，累加后得到系统的整体复杂度C 这里的子模块复杂度cp是一个经验值 需要注意：如果一个子系统特别复杂，但是很少使用及修改，也不会对整体复杂度造成太大影响。例：spring框架内部代码较为复杂，但由于几乎不需要我们去变动，所以对系统的整体复杂度影响并不大 2、复杂度分类
![]()
本文主要面向业务复杂度的治理
3、业务复杂度高的影响
（1）研发成本高。需要花费更多的时间去理解、维护代码；同样的需求，可能需要要修改更多的工程和类 （2）稳定性差。过高的业务复杂度，会导致系统难以理解甚至理解出现错漏，改动代码后极易出现“按下葫芦起了瓢”的问题
02 业务系统复杂度高的常见原因
1、什么是复杂度
业界对于复杂度并没有统一的定义，斯坦福教授John Ousterhout从认知负担和工作量方面给出了一个复杂度量公式
2、复杂度分类
本文主要面向业务复杂度的治理
3、业务复杂度高的影响
（2）稳定性差。过高的业务复杂度，会导致系统难以理解甚至理解出现错漏，改动代码后极易出现“按下葫芦起了瓢”的问题
业务系统复杂度高的常见原因
1、业务系统模块多，关系复杂，互相依赖
如下边的业务处理代码，不点进具体的方法，根本不知道做了什么：
/*** 处理业务逻辑*/public void handleBiz(){step1();step2();step3();}
再比如下边的业务处理代码，做了方法定义外的操作，开发者很容易遗漏重要信息
/*** 转换对象方法*/public Po convert(Dto dto){Po po=new Po();po.field=dto.filed;//更新操作，不应该放到转换方法里mapper.update(po);//调用rpc服务，不应该放到转换方法里XXGateway.update(dto);return po;}
大量的变化造成花在系统上的时间增多，提升了开发时间权重；
降低业务复杂度的方法
1、抽象分治，分解复杂度
（1）领域拆分
a、实体类的系统。映射到物理实体，比如商品中心、用户中心、地址服务等
b、流程类系统。映射到多个角色的串联协调工作，比如供应链上单，审核类系统等
供应链领域化拆分例子：
（2）领域之内拆分
01、变与不变拆分。将不易变化的系统能力拆分出来，上层适配各种业务逻辑，底层提供稳定的能力单元。如营销领域，将优惠卡券这个不易变的内容作为一个子系统来设计。
背景：营销域即有面向商家的营销资质、营销活动管理，又有面向C端用户根据活动领红包、优惠券的高频业务
其中，B端业务逻辑较复杂但请求量小，C端业务逻辑较简单但请求量大
治理方案：【变与不变拆分】+【场景BC隔离】
建设营销B端服务。提供面向商家的营销活动管理，重心放在建设复杂的营销活动模型、处理复杂的业务流程；
建设C端用户系统，提供面向C端客户的领营销资产、消费影响资产服务，重心放在高并发、高可用建设；
建设底层营销资产管理服务。如卡券中心提供生成卡券、消费卡券、查询卡券等基础稳定的服务。相对不易变化，不需要经常迭代；
上层的服务根据不同的业务场景来决定把卡券发给谁、什么时候发、发多少，业务场景变化或者有新的场景时，经常需要迭代
背景：
02、技术上。为了提升性能，高频操作场景会先操作redis缓存，再异步同步DB数据
治理方案：抽象业务+变与不变拆分
库存操作业务可以抽象为：根据用户条件、库存划分规则定位到需要操作的库存记录，按照库存记录对库存进行操作
变与不变拆分：01、DB库存操作、Redis库存操作建设为底层支撑能力，仅提供基础的库存加减能力，尽量保障其不变性，避免大幅度的改动影响所有业务 02、根据业务逻辑去定位库存，这部分相对来说变化比较频繁，由上游业务系统进行处理
库存架构如下图：
（3）子领域/系统 内部拆分
01、代码分层。确定每一层的分工；确定调用关系，不能跨层调用；如果下层能解决的复杂性问题，不要放到上层，如：外部接口调用失败重试，不能放到服务层
接入层：负责服务接入，包含日志打印、异常处理、参数检查、权限检查等接入层能力。该层不包含业务逻辑
@Overridepublic InsertDeptResponse insertDept(InsertDeptRequest request) {//入参记录log.error("insertDept request:{}",request);InsertDeptResponse response=null;String umpKey = XXX;Profiler.registerInfo(umpKey, true, true);try{//校验入参，如果校验不通过，checkParam方法会抛出参数校验不通过异常checkParam(request);//权限校验，如果校验不通过，checkAuth方法会抛出权限校验不通过异常checkAuth();//业务逻辑处理，内部可能会抛出影响可用性的异常和不影响可用性的异常response=XXFacade.insertDept(request);}catch(BizRuntimeException ce){//不影响可用性的异常log.error("XXX");//组装返回值response=XXX;}catch (Exception e) {//影响可用性的异常log.error("XXX");//组装返回值response=XXX;Profiler.functionError(info);}log.error("insertDept response:{}",response);Profiler.registerInfoEnd(info);return response;}
业务逻辑层：整体负责接口中的业务逻辑处理。主要进行各领域间的逻辑串联、数据处理 领域服务层：以某个核心概念为核心组件领域服务，如权限服务，将该领域相关能力进行收口，提供给上层可复用的能力 数据层：负责与数据库或者外部服务进行数据交互
背景：供应链业务中，二维码牌安装服务流程特别复杂，理解与修改都很困难；流程中用到很多数据，在不同方法中被重复获取
结构化分解后的流程：
拆分后主方法伪代码：
public void setUp(){//参数检查阶段paramCheck();//初始化阶段initData();//业务校验阶段businessCheck();//业务执行阶段businessExecute();}
（4）方法逻辑拆分。职责单一、命名准确
（5）系统合并
2、添加注释，使代码易懂
（1）代码思路要通过注释/自注释标识出来
例：redis模式的库存操作，在处理逻辑主方法中，较为清晰的标注了每一步核心逻辑
（2）注释应当能提供代码之外额外的信息
01、一些不那么直观的代码，可以附上原因
3、配置化
（1）业务对象可配置
（2）业务规则可配置
背景：物流能力中心项目中，要计算不同的仓类型、不同的资源类型（人员、场地、物资、车辆等）、不同履约时效的履约能力，每种场景接入的参数都不一样，计算工时也不一样，算法还经常需要调整，如果使用硬编码的方式，要对几十种业务组合编写业务逻辑，工作量大，维护困难
（3）业务流程可配置
TMF2.0 配置流程：
4、使用规范降低复杂度
（1）代码规范
（2）架构层级规范
例：物流百川三层架构，定义了系统层级，使系统交互有序
3、先轻后重。先做简单逻辑再做复杂逻辑。先迁移轻业务，有了经验后，再去迁移更复杂的重业务
