北京和杭州的设计最大不同是
北京有个 api ,不关心存储.
杭州在重构的时候也遇到这样的问题.
1. 先把 dal 抽取出来+ 一些通用的功能.
2.还是直接整个功能抽取过来,有较强的业务含义.
账单系统,订单系统,发单抢单系统.收银系统. 新业务可以跨过发单抢单系统来操作. 收银台可以把 sdk 和后端一起封装掉,优惠模式固化.
这样系统之间就互相解耦了. 数据传输需要api系统传递. 系统多了以后 ,底层对各个字段都要有判空处理,默认值处理.
订单信息可能必须.
一开始司机 id 必备的,后来司机 id 不必备了,抢单系统也不必备了.
如果抢单逻辑在订单里的话,代码就很难分离了.
重构的好思路是:
新的系统直接依赖数据库. 然后旧的系统再对接到新系统的 api 上.
转播
