看一些具体的业务逻辑，不要去谈论真空中的球型鸡

• 视频号订单
• 销售员分销
• 平台抽服务费
• 储值支付订单

一开始就只有一个常规购买。所有的业务都是逐步以增量需求的方式加进去的。当然每个业务也完全可以整体删掉。问题是，谁的代码是可以支持快速删掉一块业务的？删掉恐怕不比加进去更容易。

忽略券，满减满折，限时折扣等简单的促销活动。还有如下功能点需要与上述业务做乘积。也就是每个功能点都要考虑不同业务施加的影响。

• 下单 -> 改价 -> 支付前取消 -> 支付 -> 发货 -> 收货 -> 售后期结束 -> 部分退货审批通过 -> 整单全退
• c 端订单列表，筛选
• b 端订单列表，筛选
• c 端订单列表项显示倒计时
• c 端订单详情，状态标题，状态描述
• b 端订单详情，状态标题，状态描述
• 分佣单列表，筛选
• 分销单列表，筛选
• 账户流水列表，筛选

功能点举例

• c 端订单详情，如果未支付，应该显示待支付。如果团购未成团，应该显示待成团，并倒计时。如果待自提，显示待自提。
• c 端筛选（待付款，待发货，待收货，其他，售后中），b端筛选（待付款，待发货，已发货，其他），账户流水列表筛选（结算中，交易完成，交易关闭）。如果是自提，没有待发货，直接进入待收货列表。
• 售后期结束，要分享返佣（如果有），要给分销的销售员分账（如果有），平台分账服务费，如果有退款需要对商家分账部分退款费用回退
• 支付完成，如果有分享返佣要开始展示待分账，如果有分销的销售员要开始展示待分账，如果是团购要成团，要停止待支付的倒计时，要计入平台分账的待收，如果是储值支付的则用储值的抽服务规则，并计入储值的账单流水。

if/else比较集中的地方

• 单一状态机无法满足
  • 无论是团购，快递还是自提订单，流程是有差异的，但是列表都是共享的。c 端，b 端，账户流水列表。不同的状态机要适配到同一个列表里。
  • c 端，b 端，账户流水列表对状态的划分都是不同的。而且都要求排序和分页。
• UI集成：同一个UI展示位，例如订单详情的状态描述，在c端和b端的行为不同，对于不同的订单类型，处于不同状态的订单，都有不同的展示需求。
• 流程集成：支付完成，售后期结束等时间点需要同时发生大量不独立的业务（比如互斥的规则，互相影响的分账比例和金额）
• 数据库表的集成：订单表的字段总是不够用，做一个新需求，就得加几个字段。

表在一起，流程节点在一起，展示的UI就是同一个。对于以上业务上高度集成的 if/else，无论是DDD还是微服务，都是拆了半天，最终在某个角落里仍然是纠缠在一起去实现的。不要去谈论什么真空中的球型鸡，空谈理论上的解决方案。现实的需求就是要这也集成那也集成，不可能让你独立正交，需求都是非常合理的，不是为了复杂而复杂。以上就是一个极其简单平凡的小程序的前后台业务，就要搞个代码拆分也是极其困难的。如果只是无脑模仿，见到CRUD就拆个微服务，就等着哭去吧。