重构实战落地--水平切割和跨层访问哪个好

系统要重构了,水平切分大体明确.

本来期望水平拆分成不同的jar和api,实现微服务之前的部署.

但是实际操作起来

1. 会导致要不停的拆分子模块,

2. 每个子模块都会有外部边界.

     都需要配置 dubbo 的consumer ,但是又会最终在一个jvm上运行,技术边界导致不可能完全子模块化. 需要将所有的dubbo配置和mybatis配置放在一起. 然后各个子模块,按需封装wrapper.

所以说最终说来,还是需要一个 类依赖检查工具.

对于要重构的老服务,

1. 已经有大量的跨层调用,

2. 还有就是大量的获取多余的属性, (直接调用 DAO的getBean,调用集成层的getOrder)

3. 还有就是大量未经收缩形参调用. 这种如何落地. updateState(driverId,normalState)

4. 其他:

                    4.1 流程杂糅. 比如 N个帐户转账,司机流水,司机状态变更.

                     都放在accountTransfer 里,但只有司机分润和逆分润会转账.

                    4.2 大段代码代码

 

落地: 每周进行codeReview. 找到可以重构的点.进行TODO 书写.

或者通过牛逼的依赖检查工具,检查出老的代码,自动添加TODO到代码中.但是这种工具风险太大,也容易错误.

随着收缩形参之后会有大量的service,通过进一步的分类细化到不同的类中.

对业务的需求理解产出.

   1. 流程图. 主流程缩放框架. 整理出对应的外部模块

   2.