一次重构不够，我们又推倒重来：电子面单架构的两次升级

一次重构不够我们又推倒重来电子面单架构的两次升级摘要本文完整复盘了多平台电子面单取号引擎从“能跑就行”的杂烩式大方法到第一次策略模式雏形已上线再到当前流程编排策略模式彻底解耦含抖音接入的两次架构升级历程。阐述了每次升级的动机、解决的问题、遗留的局限以及最终带来的开发效率提升与线上风险降低。系列导航系列开篇从“能跑就行”到“整洁架构”上一篇数据库查询优化让多包裹取号快一倍本文两次架构升级完整复盘下一篇常量与配置集中管控改造很多架构重构做完就结束了。但我们的电子面单引擎重构完上线后发现接第二个平台时又卡住了。于是有了第二次重构。这篇文章复盘这两次升级的全过程——不只是技术选型更是对“什么时候该重构、什么时候该停手”的思考。文章目录一次重构不够我们又推倒重来电子面单架构的两次升级一、老代码时代一个方法统治所有1.1 代码形态1.2 核心痛点二、第一次升级策略模式雏形已上线2.1 升级目标2.2 核心改动2.3 第一次升级后的静态结构2.4 第一次升级的时序流程2.5 解决的问题2.6 遗留的局限三、第二次升级流程编排策略模式彻底解耦当前3.1 升级动机3.2 核心改动3.3 第一次升级 vs 第二次升级核心差异3.4 第二次升级后的静态结构3.5 第二次升级后的时序流程四、两次升级综合收益对比五、当前架构全景六、系列导航与参考延伸阅读Java 23种设计模式实战系列七、一起交流共同进步一、老代码时代一个方法统治所有1.1 代码形态最早期的电子面单取号逻辑全部集中在一个超过 500 行的大方法中getQiMenWaybill。这个方法集请求构建、API调用、响应解析、持久化、异常标记于一身。// 伪代码一个方法做了所有事publicvoidgetWaybill(TocWmsPickTicketticket){// 100 行构建奇门请求// 50 行调用淘宝SDK// 100 行解析响应JSON// 80 行保存运单、绑定工作单// 50 行异常处理}1.2 核心痛点新增平台必须改核心代码每接入一个平台如从奇门扩展到抖音都要在这个大方法中增加大量if-else分支代码快速膨胀。一个平台改动影响所有平台修改奇门的请求逻辑可能误伤抖音的解析逻辑。测试需要全量回归任何一个改动都必须测试所有已接入平台回归成本极高。配置硬编码AppKey、Secret、Token、常量等散落各处。性能隐患包裹循环内重复查询数据库。设计模式视角这种“上帝方法”是典型的违反单一职责原则SRP的反面教材——一个类承担了太多职责任何一个维度平台、快递、流程的变化都会导致修改维护成本随功能增长指数级上升。在《Java 23种设计模式从踩坑到精通》系列中我详细拆解了六大设计原则如何指导架构演进欢迎延伸阅读。二、第一次升级策略模式雏形已上线2.1 升级目标将奇门平台的取号逻辑从“大方法”中解耦出来为后续接入新平台打下基础。2.2 核心改动引入“模板方法三层策略”的雏形架构将取号流程抽象为固定的步骤各平台的差异通过接口实现来隔离。2.3 第一次升级后的静态结构下图展示了第一次升级后的类关系虽然有了策略接口和模板编排器但策略实现类内部仍混杂了持久化和异常标记等逻辑策略工厂也仅使用单维度platformCode作为路由 Key。2.4 第一次升级的时序流程从动态视角看第一次升级已经建立起了“构建→调用→判断→解析”的标准流程骨架但各步骤内部的职责划分尚不纯净。2.5 解决的问题维度改造前改造后代码组织500 行大方法模板方法 策略接口职责分离奇门维护与其他平台逻辑混杂独立策略实现可单独修改代码复用无模板骨架复用测试范围全量回归仅需测试变更平台2.6 遗留的局限第一次升级只完成了奇门一个平台的改造当需要接入抖音时以下问题暴露出来1. 策略工厂路由仅用单一编码StrategyFactory使用platformCode作为 Map Key导致抖音普通和代发策略互相覆盖requestMap.put(DY,newDouYinRequestStrategy());// 普通requestMap.put(DY,newDouYinDaiFaRequestStrategy());// 代发覆盖了上面2. 解析器混杂持久化逻辑QiMenResponseParser和DouYinResponseParser内部都包含了commonDao.store、markTocAuditException、bindTocWorkDocAndWayBill等非解析操作。新增平台时这些逻辑被复制粘贴维护成本高。3. 顺丰子母件逻辑未完全解耦顺丰超过10件需要分批取号的逻辑仍然部分散落在策略层未彻底迁移到编排层。4. 配置硬编码与常量散落AppKey、Secret 硬编码在代码中平台编码、上下文 Key 等魔法字符串散落各处。三、第二次升级流程编排策略模式彻底解耦当前3.1 升级动机接入抖音平台时第一次升级的局限集中爆发策略路由覆盖、解析器越权、硬编码维护困难、常量散落导致修改遗漏。如果不彻底重构后续接入京东、拼多多等十余个平台时维护成本将呈指数级增长。3.2 核心改动1. 复合Key路由引入platformCode _ platFormOriginal复合 Key与ApiInvoker路由规则统一。将 Key 构建方法收口到TocWmsSourcePlatFormType.buildCompositeKey。// 改造前单维度互相覆盖requestMap.put(DY,newDouYinRequestStrategy());requestMap.put(DY,newDouYinDaiFaRequestStrategy());// 改造后复合Key各自独立requestMap.put(DY_DEFAULT,newDouYinRequestStrategy());requestMap.put(DY_DF,newDouYinDaiFaRequestStrategy());2. 解析器职责净化将持久化、异常标记、工作单绑定全部移出解析器收口到WaybillPersistence和模板层。解析器只做纯数据转换。3. 顺丰子母件逻辑归位将分批取号逻辑从策略层迁移到WaybillFetchTemplate.executeSFMoreTen中由编排层统一控制流程。4. 前置校验体系引入LogisticsSupportable接口门面层在请求构建前校验平台是否支持指定快递公司。错误信息中文化运营自助排错。5. 性能优化将包裹循环内的数据库查询提升到循环外一次性执行通过WaybillContext透传结果。N包裹订单的查询次数从 N 降到 1。6. 常量统一管理将平台编码、上下文Key、快递公司编码等常量统一到TocWmsSourcePlatFormType和TocWmsExpressType中并增加编码到中文名称的映射方法。这一部分的详细内容见下一篇《平台常量和配置管理从散落魔法字符串到集中管控》。3.3 第一次升级 vs 第二次升级核心差异维度第一次升级策略模式雏形第二次升级流程编排策略解耦策略接口定义了三个接口但实现类内部混杂了持久化、异常标记等逻辑策略实现类纯粹只做请求构建/响应解析/异常判断解析器QiMenResponseParser内部调用了commonDao.store、markTocAuditException所有持久化和异常标记全部移出解析器只做纯数据转换工厂路由单维度platformCode作为 Key抖音普通和代发互相覆盖复合KeyplatformCode _ platFormOriginal精确路由持久化散落在各解析器中每个平台重复实现统一收口到WaybillPersistence全平台复用前置校验无引入LogisticsSupportable接口门面层统一校验子母件部分逻辑散落在策略层完全迁移到WaybillFetchTemplate.executeSFMoreTen编排层统一控制常量管理散落各处统一到TocWmsSourcePlatFormType和TocWmsExpressType新增平台需要修改工厂 复制解析器中的持久化代码只需新增三个纯策略类 注册配置3.4 第二次升级后的静态结构下图展示了第二次升级后的核心类图。与第一次升级相比最关键的三个变化是策略实现类不再触碰持久化、工厂路由升级为复合Key、子母件逻辑完全由模板层控制。3.5 第二次升级后的时序流程从时序图可以看到解析器不再执行任何持久化操作所有保存动作统一由WaybillPersistence在流程末端完成异常标记也收口到了模板层的markException方法。四、两次升级综合收益对比维度老代码第一次升级第二次升级新增平台工作量改核心代码5-6天新增3个策略类3-4天新增3个策略类注册配置1-2天核心流程代码行数500行约150行约100行代码复用率30%约60%约85%数据库查询次数包裹数×N次包裹数×N次1次配置变更方式改代码重新部署改代码重新部署改配置/数据库分钟级生效错误信息清晰度“系统异常”部分清晰精确透传自助排错平台间影响全量回归工厂改动可能影响完全隔离独立部署能力强耦合强耦合可拆分为微服务五、当前架构全景六、系列导航与参考本篇文章是「电商多平台电子面单对接实战」的第十二篇架构复盘篇完整记录了电子面单取号引擎的两次架构升级历程。系列文章目录开篇从“能跑就行”到“整洁架构”第一篇奇门对接顺丰电子面单第二篇抖音代发电子面单对接第三篇抖音普通订单电子面单对接第四篇多平台统一架构设计第五篇策略工厂复合Key路由改造第六篇快递公司前置校验改造第七篇解析器职责分离改造第八篇模板方法的组合与继承抉择第九篇API调用调度层Handler分组设计第十篇奇门 trade_order_list 排查实录第十一篇数据库查询优化让多包裹取号快一倍第十二篇两次架构升级完整复盘本文第十三篇常量与配置集中管控改造后续京东、拼多多等平台专项篇延伸阅读Java 23种设计模式实战系列本文中两次架构升级的核心推动力是六大设计原则和策略模式、模板方法模式、工厂模式的组合应用。在《Java 23种设计模式从踩坑到精通》系列中这些原则与模式有更体系化的拆解。如果你对以下问题感兴趣推荐延伸阅读策略模式 vs 模板方法模式何时用策略替换算法何时用模板固定骨架工厂模式简单工厂、工厂方法、抽象工厂如何在架构演进中逐步升级六大设计原则开闭原则、单一职责、依赖倒置……它们如何指导每一次重构决策《Java 23 种设计模式从踩坑到精通》系列开篇从踩坑到精通 —— 总览与导航策略模式 —— 算法族的封装与切换模板方法模式 —— 定义算法骨架交给子类填充细节工厂模式 —— 简单工厂→工厂方法→抽象工厂全演进学习建议电子面单系列侧重架构演进的真实历程设计模式系列侧重理论体系与设计思维。两者搭配阅读既能看懂一个系统如何从“能跑”进化到“可插拔”又能掌握指导每次升级的设计原则形成“实战→理论→反哺实战”的闭环。七、一起交流共同进步架构演进从来不是一蹴而就的第一次升级为第二次升级铺了路第二次升级为未来十余个平台扫清了障碍。如果你也在做类似的架构重构希望这个真实的演进历程能给你一些启发。第一次重构教会我们“怎么拆”第二次重构教会我们“怎么拆得对”。架构演进从来不是一蹴而就而是在正确的方向上逐步逼近。关注我点击上方“关注”第一时间获取系列更新推送。留言讨论您在项目中有过“第一次重构后发现不够彻底又进行了第二次升级”的经历吗是什么驱动了第二次升级欢迎在评论区分享。分享转发如果本文对您有帮助请点赞、收藏、分享让更多同行看到。