新入手一个新系统,如何重构和梳理

难点, 对系统依赖理解变更.:

1. 变正向调用 为下游系统,传一个 id,然后通过这个 id 去查. (流水系统变存储为业务系统)

2. 两个流程拆分后. 至少会出现1.上游 -- 边界转换类 -- 2.下游支持接口.(业务无关.)
支付,业务计算的乘客支付数据payId和 clientPayParam 传递给转换成,然后在调用不同的渠道支付(phoenix,企业支付,第三方商户支付.)
有时候边界转换类可以变成集成类(属性+方法). xxxManager父类,含抽象属性. 各个实现类调用下面的具体渠道的 service.
manage 抽象父类,下含有抽象属性.
子类里才真正的将属性泛化,抽取具体的数据.
抽象父类+抽象属性是共同存在的. 这个是技巧+难点.
**简化了父类create逻辑.**

3. 大的结构模型有 支撑组合结构 + 引擎回调结构(固化流程,同时使上游的分叉减少,减少这部分人力和组织. 但同时可变性较少. 无法引入商户等.).
4. 有的数据可以通过 result 返回. 而不是上游先算出再下传(减少计算所需的业务知识)
例如支付的金额中 乘客余额支付的金额,乘客支付宝支付的金额.券支付的金额.
原业务系统,这块的计算都放在 bill 里面的. 对接北京后,就需要把这块逻辑抽出来.然后传递到北京.由北京计算实际金额. 然后回传给业务方.
**故支付里的支付数据可能是多次计算得到的.**

如何梳理?
1. 了解业务
2. 了解层次
3. 了解各个层次是否要关心这些 type 值.
代保养感觉都要重新写一套.各种并行的 type.没有很好的过滤掉.将上层业务区别下沉到了底层.就是为了方便统计.特别是state 和 payType.
哪些不合理. 层次,状态,类型?
如何整改这些不合理? 特别是影响到各种统计业务.对他们来说也是解放.

如何重构,如何兼容历史数据?
1.增加新字段,老字段不动.
新的业务都利用新字段判断.老字段只是插入和兼容大数据统计.
2.待新的业务变更时.通知大数据,让其修改对应的 sql. 因业务驱动修改.而不是重构而修改. 没做,只是影响了新业务.影响面小.
兼容老数据而做的妥协.