订单状态机

0 前言

电商平台所有模块中，订单系统作为比较核心的模块，它决定了整个流程能不能顺畅的执行，起着承上启下的作用（下单、支付、履约、售后、清结算、营销活动）。

订单系统的设计主要需要考虑订单字段、业务流程、状态机三大个方面，这些内容决定了订单系统稳定性与扩展性。

2 订单流程

订单流程指整个订单从产生到完成的整个流转过程，它包括正向流程和逆向的流程。

3 订单状态机

状态机表示了一笔订单的生命周期，按照一定的方向通过触发不同的事件产生数据流转的过程。

 

状态机v2.0

随着业务快速发展，我们的状态机也在逐步完善，在完善的过程中我们遇到两个问题

1. 如何提供更多的订单状态来描述现实世界？
2. 在提供更多的订单状态后，同时节省状态机维护成本？

为了解决这两个问题，我们采用大状态+小状态的设计。主、子订单上只维护大状态流转，抽象出物流、售后两个领域分别去维护各自的小状态。这样保证了主子订单上的状态不会特别多，同时又可以通过不同的领域中的小状态去满足业务需求。

主、子订单变更规则

• 正向状态是当全部子订单向前流转时，主订单才会向前走；
• 逆向状态是当子订单全部变成15(售后中) 主订单才变售后中.   子订单全部变成16(售后完成)主订单才变售后完成  子订单全部变成11(取消)主订单才变取消；

 

状态机在APP端的体现

团长C端提货界面

用户C端提货界面

 

思考与改进

1 目前物流领域的状态机只针对团长端开放，并没有针对C端用户开放。WMS和TMS作业都是按照团长+SKU纬度，团长收到货后承担这二次分拣的职责，由团长决定用户的货是否真的送达，所以WMS和TMS回传给订单的消息对用户是不准确的。

问题举例

小明在A团长下单5个苹果

小红在A团长下单5个苹果

23点仓库开始作业，发现一共只有5个苹果。

1. WMS TMS 下发出库、配送指令 A团长+5个苹果
2. OMS收到指令按照团长纬度更新订单状态，此时小明、小红的订单状态都被更新为司机送达
3. 团长收到5个苹果后，选择把苹果全部给和他关系较好的小明。

此时小红没收到货、同时看到自己订单状态为司机送达就会很懵逼，这也是目前为什么履约状态只针对团长开放的原因。谁到货谁没到货团长线下决定的。