最佳实践 重构系统往下抽,还是往上抽

北京和杭州的设计最大不同是

北京有个 api ,不关心存储.

   杭州在重构的时候也遇到这样的问题.

1. 先把 dal 抽取出来+ 一些通用的功能.

2.还是直接整个功能抽取过来,有较强的业务含义.

    账单系统,订单系统,发单抢单系统.收银系统. 新业务可以跨过发单抢单系统来操作. 收银台可以把 sdk 和后端一起封装掉,优惠模式固化.

    这样系统之间就互相解耦了. 数据传输需要api系统传递. 系统多了以后 ,底层对各个字段都要有判空处理,默认值处理.

    订单信息可能必须.

    一开始司机 id 必备的,后来司机 id 不必备了,抢单系统也不必备了.

    如果抢单逻辑在订单里的话,代码就很难分离了.

    重构的好思路是:

　　　　新的系统直接依赖数据库. 然后旧的系统再对接到新系统的 api 上.