系统要重构了,水平切分大体明确.
本来期望水平拆分成不同的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.