订单交易最基础的部分是交易流程，从设计最小闭环开始，逐渐往最小闭环里补充交易流程。但如何设计最小闭环呢，这里我们要先介绍订单交易里两个最核心的元素根据场景来定义状态。核心的部分在于

　　1、订单状态

　　2、订单操作

　　订单状态

　　订单状态是定义订单将按照哪几个步骤进行的依据，就像我们人的生命周期一样，有婴儿期、少年期、中年期、老年期。订单状态具有几个特点

　　顺序性：订单状态需要按照一定的规则，从前之后顺序发生，不能跳跃，不能逆向。

　　特殊性：订单状态包容异常情况，在顺序的过程中都可能因为一些操作随时进入异常态。

　　可扩展性：订单状态可以随着业务场景的需要添加，但一般不会删减。这样会影响历史数据。

　　订单操作

　　订单操作是基于订单状态下，可给用户触发的对该订单的操作。订单状态一般都由订单操作触发才会发生改变。比如买家点击收货按钮后，触发订单由待收货状态变成了已完成状态。订单状态一般设计为买家和商家共用，但订单操作一般是独立设计的。所以在订单操作设计上就需要考虑对订单功能的用户群体包括哪些。常见的用户群体包括买家、商家、平台管理员。

　　一些特殊交易平台的订单还包括其他角色，比如够格产品上有代售功能，就包括的红人角色。在这里因为管理员是超级权限，基本啥都能干，还可能还会设置等级。所以我们就不做为讨论范围。接着再考虑给对应角色开放什么权限前，先确认改状态下可以有哪些权限，然后再根据角色身份进行分布。

　　划分用户角色

　　定义该状态下所有订单操作

　　根据角色设置订单操作

　　下面我们就基于订单状态来讨论下买家和商家对应的订单操作。

　　在订单状态上，基于订单交易场景下，完成最小闭关搭建，一般常见的订单交易最小闭环流程如下

　　待支付 – 待发货 – 待收货 – 订单完成 四种状态流转。

　　待支付：虽然系统设计上尽量让用户一步完成支付了，但未支付的状态还是要保留，因为你永远不知道用户啥时候就没支付。

　　待发货：支付完成的订单，此时买家处于等待状态，后面基本不需要做什么操作。会通知商家进行发货。

　　待收货：商家已发货订单，此时设计最关键的功能便是物流跟踪。

　　订单完成：当买家点击收货后，这笔订单才算完全交易完成。

　　在基于四种订单状态，我们从商家、买家两种用户角色上进行划分。比如待收货状态，一般包括“确认收货”“取消订单”“查看物流”操作。确认收货是相对买家的权益保护，只能开放给买家。取消订单按道理商家也可以开放，但一般出于对订单保护，尤其在卖家已经发货的状态下。不会开放给商家，只会开放给买家。查看物流是双方都可以进行的操作。所以我们可以安排如下：

　　商家：查看物流

　　买家：确认收货，取消订单，查看物流

　　按照这个思路，我们就可以得出待支付、待发货、待收货、订单完成状态下的订单操作。从而得出最小闭环的订单流程。后面可以基于这个最小闭环完善订单流程。一般常见的操作包括:

　　在状态时间轴上设置系统定时器功能，替代人工操作更改订单状态。如自发货算起，15天后自动收货。

　　出于业务需要，添加新的订单状态。比如拼团功能需要有待成团状态。

　　出于业务需要，添加新的订单操作，比如商家可能无货了，还没修改库存。当有人下单时需要给卖家取消订单操作。需要在待支付那里商家端添加取消订单操作。

　　下面是淘宝的订单状态和买家对应的订单操作。

　　不能忽视的订单异常状态