此是我在订单(买家)写业务重构中使用的设计模式手法整理归纳，抛砖引玉。
- 业务现状
- 功能拆解
- 使用模式解决问题
- 总结
业务现状
公司做出口代购业务，即典型的电商业务。买家，商家，商品，促销，物流...电商业务应用尽有，除此之外具备代购自身的业务如，采购，质检，仓管，财务风控等。
项目现状是使用脚手架生成多模块工程，DB按分表设计，面向微服务体系，但服务自身业务实现却是铁板一块，面向过程式的代码设计，无法快速响应业务需求，维护成本颇高。
功能拆解
订单（买家）领域，是业务流量入口，这部分需求变化尤为频繁，如何解决项目稳定且快速适应业务变化呢？第一步功能拆解：
整体为框架+业务实现，功能如下：
- 框架：定义且组合业务流程
- 功能部件：模版，模版实现，业务服务发现，业务流日志聚合
- 业务实现：专注业务实现
- 功能部件：前置验证各端输入参数，分单，运费计算，红包折算，优惠券折算，积分折算，费用聚合（整体扣减），重组调用订单服务DTO等
领域模型如：
order domain
使用模式解决问题
- 问题1：facade模块业务实现如何迁移？
- 解决：facade模块依赖抽象BaseOrderCreatedTemplate模板，符合OOP的依赖倒置原则
- 问题2: BaseOrderCreatedTemplate模块如何定义？
- 解决：使用模板方法模式抽象模板分两大部分，其一为invoke方法，依次调用模板定义的所有抽象方法，如过滤，分单，订单上下文，计算费用
- 问题3: 模板与具体实现如何解耦？
- 解决：使用桥接模式分离模板与业务具体实现
- 问题4: 输入参数验证如何扩展，比如双11需要新增验证
- 解决：使用责任链模式，支持增加任意验证且不无需修改已存在的验证逻辑
- 问题5: 费用计算如何支持扩展
- 解决：使用策略模板方法模式，即子类只实现特定计算逻辑即只输出实际折算后的价格，父类模板遍历所有的子类费用计算完成后，再次聚合算出最终应支付价格
- 问题6: 如何拼装调用订单service DTO对象
- 解决：定义Compos接口，输入原始request输出拼装后的DTO即可
- 问题7: 如何定位业务具体实现
- 解决：使用“服务发现”LookupService，根据接口版本，终端，活动名称查找具体服务实现，如：v1_11_pc_Counpon_Amount 表示接口v1版本双11PC端优惠券折算，其魔力在于根据规则找到服务实现，规则可复杂也可简约
- 问题8: 如何聚合流程日志
- 解决：定义日志聚合器OrderCreatedLogAggregate，在定单模板中只需append 日志内容，流程只需完成后输出格式化后的内容即可
- 问题9: 如何共享领域上下文
- 解决：使用享元模式存储订单创建上下文需要复用的对象，具体实现为threadlocal存储上下文对象
- 问题10: 如何复用已存在的功能模块，如何费用计算
- 解决：约定配置优先即所有抽象实现都可以基于配置指定方式，如双11运费券费用计算复用618运费逻辑：order_11_v1_pc_ship_Amount=order_618_v1_pc_ship_amount，如果没有配置则根据URL规则匹配业务具体实现
总结
优点：
- 主要使用类桥接，模板，策略模式分离流程与实现，在复杂都业务中能较好都应对业务需求变化，可以任意替换具体实现。
- 工程结构按业务实现定义包名，简洁清晰
- 接口、方法定义契约统一
- 主体设计思路，适用于其他复杂的业务，如运单，采购领域
缺点：
- 业务分散，基于抽象或接口串流程，代码实现定位难
- 框架编写与业务实现伙伴要有良好的沟通协作