关于状态机的一个极度确切的描述是它是一个有向图形，由一组节点和一组相应的转移函数组成。状态机通过响应一系列事件而“运行”。每个事件都在属于“当前” 节点的转移函数的控制范围内，其中函数的范围是节点的一个子集。函数返回“下一个”(也许是同一个)节点。这些节点中至少有一个必须是终态。当到达终态， 状态机停止。

　　由上述定义可以看到，状态机的概念是用来表示按照一定的方向通过触发不同节点产生数据流转的过程。在订单中通过情景触发订单状态的变化来表达订单流转的过程就是订单状态机。

　　电商

　　O2O

　　电商和O2O的主体流程是相同的，不同的在于物流配送环节电商较O2O更为复杂，此处只表明了主要的订单状态机，仓储物流内的物流单流转不在此范围内。状态机原则上使用结果值而不使用过程值，比如使用支付成功作为节点而不使用支付中作为节点。

　　订单状态机要融合订单流程来设计触发节点，订单流程的逻辑点要多于状态机，一般在当前流程环节完成后最后更新状态机。

　　订单推送

　　当状态机发生变化时，需要将对应的变化情况告知给相关人员以便了解当前订单的情况。这就是订单推送的作用。

　　订单推送的触发依赖于状态机的变化，涉及到的信息包括

　　推送对象(用户、物流人员、商家)

　　推送方式(push，短信)

　　推送节点(状态机)

　　订单的演变

　　电商平台的搭建变迁也是订单逐步稳固发展的过程。我们来看下订单的发展过程，结算环节由于是一个比较大的话题，这里面不展开说明了。

　　订单第一阶段：实现订单流转

　　平台搭建的第一阶段要实现基本的订单流转，支持一些营销活动的购买(这里依赖附属系统的搭建情况，这里默认认为具备基本功能)。

　　实现订单的生成、生产

　　支持订单审核(初期可支持人工审核即可)

　　支持用户端显示订单相关信息

　　支持促销金额的计算

　　这个阶段搭建时核心是解决订单的基本流转，所以原则上一些功能可以后续再逐步完善。比如催单、拆单、系统审核等。

　　另外在搭建订单结构的时候如果条件允许，在设计之初可以就考虑用子母单的形式，即两层结构

　　母单负责订单整体信息的记录

　　子单记录单个商品的详细信息和金额情况

　　订单第二阶段：平台化搭建

　　随着平台的发展，越来越多的接入方需要订单的支持，POP平台的商家接入、第三方仓配的接入，更多快递合作伙伴的接入等等。订单的功能进入第二阶段的扩充。

　　提供订单soa服务

　　支持跨平台交易单生成(即同一个大交易单内既有商家商品又有自营商品或者是多个商家的商品)

　　对接多个仓库，支持移仓模式

　　根据仓配情况计算预计送达时间(订单promise服务)

　　支持拆单、合单逻辑(配送单、支付单等)

　　支持快递分单

　　提供更丰富的订单推送服务，完善订单状态机

　　这里说几个订单复杂化以后需要注意的细节

　　订单子母单结构，便于将信息进行梳理，减少耦合