正文

最近在做订单及支付相关的系统，在订单表的设计阶段，团队成员就‘订单状态’数据库字段设计有了一些分歧，网上也有不少关于这方面的思考和探讨，结合这些资料和项目的实际情况，拟对一些共性问题进行更深一层的思考，笔耕在此，和大家一起探讨。

1. 问题综述

这里的分歧点即有团队内部的分歧点，也有网络上常见的一些分歧点，先将存在的分歧点抛出来：

1、订单表的‘订单状态’字段对应的字典值应当包含哪些状态值？对于‘已评论’、‘已退货’、’已退款’这类状态是放到‘订单状态’中？还是独立一个字段标识？

2、订单表的‘订单状态’字段对应的字典值如何表示？可选项有：使用数字标识、使用多‘位’存储方式标识、使用具有明确业务含义的英文字符串标识；

3、订单表的‘订单状态’字段使用何种类型？可选项有：number(N)、char(N)、varchar2(N);

如果嫌分析过程过于啰嗦，可以直接拉到最后看结论。

2. 业务分析

我们先不去看问题，先来看看和‘订单（Order）’实体相关的业务是怎样的。下面我们会针对可能改变订单实体状态的行为已经状态变化的可能性进行详细的分析。

订单业务实体相关的业务流程如下：下单（create）–> 买家付款（pay）–> 卖家发货（deliver）–>买家收货（receive）–>退货（rereturn）；此外，还有退款（refund）和评论（comment），这两个行为比较特殊，其前向行为可能存在多个。

首先，可以改变订单业务状态【这里的状态不是指‘订单状态’（OrderState）这个数据库字段，而是指实际业务状态，我们简记为（BizState），以和OrderState区分开】的行为有哪些？按照典型电商的业务流程，主要的行为（action）有：下单、付款、发货、收货、退款/退货、评论；每一种行为的发生，都会导致订单的业务状态BizState发生变化，比如‘下单’行为会创建订单，‘付款’行为会使订单变为‘已付款’，‘发货’行为可以使订单状态变为‘已发货’，‘收货’行为会使订单状态变为‘已收货’，‘评论’行为会使订单状态变为‘已评论’。‘退款/退货’action不是所有订单都支持的，为减小复杂度，暂不考虑它们。

其次，细分下每种action对BizState带来的影响，会发现还可以细分为四种子状态（subState）：action未开始（标记为0）、action进行中（标记为1）、action成功（标记为2）、action失败（标记为3）；理论上，将所有action的所有subState进行排列得到4*4*4*4*4=1024（暂未考虑‘退货’）；实际上，很多组合是没有业务意义的，是不可能存在的，比如‘未开始已付款…’（***20）这一类组合是不可能发生的，应当舍弃。用表格将上述的组合分析如下：

通过上表，我们可以发现些的规律：

‘下单’、‘付款’、‘发货’、‘收货’前四种action是存在依赖关系的，亦即后一个action依赖于前一个action的完成；所以，他们的SubState组合情况就会非常少；

‘评论comment’这个action的SubState和其他状态组合会有很多种可能性；除了前面了两行是‘X’，后面是‘?’或者‘Y’，‘？’是指需求上是否允许在对应的BizState上进行评论，如果允许，则每种BizState需要多出4种可能，这样组合的可能性就会变得很大。

没有业务意义的SubState组合被舍弃。表中的标黑单元格，表示这个BizState是毫无意义的，因为‘未下单’的订单对于我们来讲是不存在的，这类组合需要舍弃；同样的，还有很多其他的组合也是不存在的，被舍弃掉，未展示在上表中，如‘已下单已付款未发货已收货’这种。

通常某个action的SubState为‘1进行中’、‘3失败’时，会被忽略，但也有例外；比如‘付款’action的‘3失败’状态，和‘付款’action的‘1进行中’状态，具体分析见后面内容。

忽略所有action的‘0未开始’SubState状态。因为这类SubState对于BizState不会带来变化。

综合下来，我们得到上表的BizState，注意这里的Comment action未进行细化处理，如果细化处理，会发现BizState的可能性会增大很多很多。

接下来我们就之前提出的这些问题进行逐个讨论。

3. 问题一、订单表的‘订单状态’字段应当包含哪些状态值？

什么样的‘订单业务状态’（BizState）需要记录到系统层面的‘订单状态’（OrderState）字段呢？如果记录多了，则系统处理的复杂度会增大；记录少了，那么‘订单状态’（OrderState）字段就不能完整的表示出订单实体状态变化情况。

核心状态

通过上面的业务分析可知：大部分存在依赖关系的action（create、pay、deliver、receive），他们产生的合理的SubState组合是非常少的，而且他们之间的依赖是单向依赖，状态机的处理也很简单，因此，我们先将这部分BizState纳入到OrderState中：

• 等待买家付款
• 买家付款成功
• 卖家已发货
• 买家已收货

目前的订单状态流转：

‘action行为’失败的情况

对于action的SubState是‘3失败’的处理，需要针对不同的action进行分析。类似‘下单Create’这样的action，如果失败，则可以直接将OrderState置为‘订单创建失败’，因为Create action是第一个action，它的失败意味着Order实体出生即死，BizState置为终态，对于这个BizState应当纳入到OrderState中记录，不过这个OrderState其实对于用户并无多大用处，因为用户并不会关心下单失败的订单，他更关心的是重新下单；

对于‘支付’失败，则要看需求，如果需求要求用户可以继续支付，则订单需要保留，并且状态仍然为‘等待买家付款’，如果不允许再支付，则理论上可以将BizState置为‘支付失败’终态，所以，‘支付失败’的BizState终态也应当记录到OrderState字段中。

对于‘发货’失败、‘收货’失败的情况，通常是不会发生的，即使发生也不属于系统能够控制的范畴，系统记录并无意义，更具建设性的做法是通过线下手段尽快解决问题，重新发货等等，所以对于这些状态系统的OrderState字段不予记录。

这样下来我们的OrderState字典值增加到6个，加粗项为新增：

• 创建订单失败（终态）
• 等待买家付款
• 买家付款失败（终态，依赖需求而定）
• 买家付款成功
• 卖家已发货
• 买家已收货

目前的订单状态流转：

‘action行为’进行中的情况

对于action的SubState是‘1进行中’的处理，同样需要具体场景具体分析。‘付款’行为是用户发起的，但是并不是和订单系统之间的交互，涉及到支付系统的处理，这个领域也不是订单系统可控的，但关系到钱，用户比较关系，所以对于这样一个中间态，我们需要记录，以便用户通过订单系统查询订单状态，为便于用户理解，将此状态在OrderState中记为‘付款确认中’；‘发货’‘收货’进行中的情况，不是订单系统可以控制的领域，我们可以把他们当着行为‘未开始’处理，比如‘发货进行中’，订单系统的OrderState值为‘买家已付款’，但给用户看到的提示信息是‘买家已付款，等待卖家发货’，实际上这时候卖家可能正在发货中，但是用户不会去关心到底有没有打包好货物什么的，所以这类‘进行中’状态可以舍弃。这样下来订单系统的OrderState字段又多了一个字典值：‘付款确认中’：

• 创建订单失败（终态）
• 等待买家付款
• 付款确认中
• 买家付款失败（终态，依赖需求而定）
• 买家付款成功
• 卖家已发货
• 买家已收货

目前的订单状态流转：

‘action行为’未开始的情况

忽略所有action的‘0未开始’SubState状态。因为这类SubState对于BizState不会带来变化。

‘评论comment’的处理

最后，再来看看‘评论comment’这个action。如果需求上要求：只有买家收货后才能发起‘评论’操作，则可以任务‘评论comment’单向依赖于‘receive收货’行为，那么可以将这个action的subState对应的少量BizState（应当只有‘买家已评论’、‘卖家已评论’状态）纳入OrderState字段统一记录；但是如果需求是：买家在下单后就可以开始评论，比如如果卖家发货慢了，买家可以上去吐槽，那么‘评论comment’就不是单向依赖于‘receive收货’行为了，而是多向依赖于‘pay付款’、‘deliver发货’、‘receive收货’，那么这些actions的subState组合可能性就暴增，BizState的字典取值也会暴增，显然，不应当将这么多的BizState交给OrderState来记录，而应当由一个独立的数据库字段负责记录‘评论comment’的SubState，我们可以将这个字段取名为‘CommentState’（评论状态），它的字典值不多，只有：‘未评论’、‘买家已评论’、‘卖家已评论’；其实，对于前一种需求，也可以不讲‘评论comment’对应的SubState产生的BizState纳入OrderState，因为用户对于评论与否其实并不是那么关心的，也就是说‘评论comment’并不是核心业务流程，为了降低核心业务流程的系统处理复杂度，将其从核心业务流程中剥离出来较好。

综上，我们应当将‘评论comment’对应的BizState独立到一个字段中记录。

‘退货rereturn’的处理

再来看看‘退货rereturn’行为对应的BizState的处理。‘退货rereturn’并不是所有订单都会经历的，但是一旦涉及，则‘退货return’在业务流程上必定是单向依赖于‘receive收货’，所以应当将‘退货return’产生的BizState（‘退货中’、‘退货成功’，‘退款失败’和‘未退货’被忽略，见上面解释）纳入OrderState一并记录；这样我们的OrderState有多了两种字典值，这里我们不考虑一个订单中有多种商品的情况，故把‘退货成功’当着终态处理，如果是一个订单多种货物的情况，需要重新仔细分析。加粗项为新增：

• 创建订单失败（终态）
• 等待买家付款
• 付款确认中
• 买家付款失败（终态，依赖需求而定）
• 买家付款成功
• 卖家已发货
• 买家已收货
• 退货中
• 退货成功（终态）

目前的订单状态流转：