核心一句话
让业务规则：模块化、解耦、可配置、单向依赖、统一收口，做到修改一处，只影响一处。
一、最关键：做到「业务规则统一收口」
所有相同规则只在一个地方定义，禁止到处复制、到处写逻辑：
金额计算统一收口（全局唯一计算方法）
商品总价、优惠、运费、实付、退款金额
下单、支付、售后、订单同步共用同一套
→ 改一次，全系统生效，不会出现 A 对 B 错
优惠规则统一收口
优惠互斥、叠加顺序、门槛判断
→ 不分散在购物车、结算、订单多个地方
状态机统一收口
订单 / 支付 / 售后 / 物流状态流转只在一个状态机管理
→ 不会状态乱跳、不会漏处理
库存操作统一收口
扣库存、返库存只调用一个方法
→ 不会多扣、少扣、不返
只要统一收口，就从根源避免 “牵一发而动全身”。
二、强制「模块化 + 低耦合」
把电商商城系统拆成独立领域，互不渗透、互不依赖：
商品模块
购物车模块
结算模块
订单模块
支付模块
售后模块
营销模块
用户模块
规则：
模块之间只通过接口 / 事件通信
不直接调用内部方法、不直接操作别人表
不跨模块写业务判断（如订单里写优惠逻辑）
效果：
改售后 ≠ 影响支付；改优惠 ≠ 影响库存
三、严格「正向与逆向规则解耦」
90%“牵一发动全身” 来自：退款逆向逻辑混乱
必须做到：
正向（下单 / 支付）只负责正向流程
逆向（取消 / 退款）独立一套逻辑
互相不嵌套、不互相调用
通过事件驱动，而不是硬编码互调
这样：
修改正向不影响逆向，修改逆向不影响正向
四、禁止「硬编码、写死数值、堆 if-else」
所有可变规则必须可配置：
订单超时时间
库存扣减时机
优惠比例 / 门槛
运费计算
退款限制
分销佣金
规则：
能配置就不写死，能动态就不硬编
好处：
修改规则不用改代码，自然不会牵一发而动全身。
五、使用「事件驱动，而非链式调用」
不要：
下单 → 扣库存 → 计优惠 → 记日志 → 通知（一串链式调用）
→ 改一个环节全链崩
要：
下单完成 → 发布 “下单事件”
库存系统订阅 → 扣库存
营销系统订阅 → 计算优惠
消息系统订阅 → 发通知
各模块各自响应，互不干扰。
修改一个订阅者，完全不影响其他模块。
六、明确「单向依赖，禁止循环依赖」
强制依赖方向：
通用工具 → 基础业务（商品 / 用户）→ 核心交易（订单 / 支付）→ 营销 / 售后
严禁：
订单依赖优惠，优惠又依赖订单
售后依赖订单，订单依赖售后
循环依赖 = 一动全动，必然牵一发而动全身。
七、建立「规则扩展点，不修改原有逻辑」
新增规则用扩展 / 插件化，不动老代码：
新增一种优惠：新增优惠类，不改动原有优惠逻辑
新增售后类型：新增处理器，不动原有售后
新增支付方式：新增适配器，不动支付核心
原则：
对扩展开放，对修改关闭（OCP）
保证：
老功能永远稳定，新功能不影响旧功能。
八、最精炼总结（可直接写入公司制度）
保证电商商城系统业务规则不牵一发而动全身，只要做到：
规则统一收口，一处定义，全局使用
模块高度解耦，不跨模块写逻辑
正向、逆向流程分离，互不嵌套
所有可变规则配置化，不硬编码
用事件驱动，不用链式强依赖
单向依赖，禁止循环依赖
扩展新规则，不修改老代码
做到以上 7 条，系统任何规则变更都只会影响局部，不会引发连锁故障。
