0 前言
电商平台所有模块中，订单系统作为比较核心的模块，它决定了整个流程能不能顺畅的执行，起着承上启下的作用（下单、支付、履约、售后、清结算、营销活动）。
订单系统的设计主要需要考虑订单字段、业务流程、状态机三大个方面，这些内容决定了订单系统稳定性与扩展性。
2 订单流程
订单流程指整个订单从产生到完成的整个流转过程，它包括正向流程和逆向的流程。
3 订单状态机
状态机表示了一笔订单的生命周期，按照一定的方向通过触发不同的事件产生数据流转的过程。
状态机v2.0
随着业务快速发展，我们的状态机也在逐步完善，在完善的过程中我们遇到两个问题
- 如何提供更多的订单状态来描述现实世界？
- 在提供更多的订单状态后，同时节省状态机维护成本？
为了解决这两个问题，我们采用大状态+小状态的设计。主、子订单上只维护大状态流转，抽象出物流、售后两个领域分别去维护各自的小状态。这样保证了主子订单上的状态不会特别多，同时又可以通过不同的领域中的小状态去满足业务需求。
主、子订单变更规则
- 正向状态是当全部子订单向前流转时，主订单才会向前走；
- 逆向状态是当子订单全部变成15(售后中) 主订单才变售后中. 子订单全部变成16(售后完成)主订单才变售后完成 子订单全部变成11(取消)主订单才变取消；
状态机在APP端的体现
团长C端提货界面
用户C端提货界面
思考与改进
1 目前物流领域的状态机只针对团长端开放，并没有针对C端用户开放。WMS和TMS作业都是按照团长+SKU纬度，团长收到货后承担这二次分拣的职责，由团长决定用户的货是否真的送达，所以WMS和TMS回传给订单的消息对用户是不准确的。
问题举例
小明在A团长下单5个苹果
小红在A团长下单5个苹果
23点仓库开始作业，发现一共只有5个苹果。
- WMS TMS 下发出库、配送指令 A团长+5个苹果
- OMS收到指令按照团长纬度更新订单状态，此时小明、小红的订单状态都被更新为司机送达
- 团长收到5个苹果后，选择把苹果全部给和他关系较好的小明。
此时小红没收到货、同时看到自己订单状态为司机送达就会很懵逼，这也是目前为什么履约状态只针对团长开放的原因。谁到货谁没到货团长线下决定的。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
