订单系统设计方法

雁过留声，人过留名；互联网业务呢，那就留下订单吧；订单是个常见的业务概念，我们去淘宝买东西、饿了么点外卖、微信服务里充话费、腾讯视频买会员等等，这些消费行为中我们都会得到一个订单。最直接的意义就是订单记录了我们的业务单据，买了什么，付了多少钱，平台交付了么，发货了么等，今天我们就详细分析下订单系统的设计

1

基于业务设计订单

互联网产品肯定是先有了业务再有了系统，而不是先有了系统再有了业务；线下业务通过互联网实现了线上化，其中多样化的业务模型衍生出了众多的订单模型，比如电子商务的订单模型，包括实物订单模型和虚拟订单模型，纯支付交易的订单模型，外卖的订单模型等等；不同的订单模型下的订单设计存在稍微的差别，但从核心内容上讲依然存在相同的内核。我们通过图1可以了解这些不同环节的订单之间的关系。

图1 不同单据间的关系

无论什么样的业务，订单作为业务的记录凭证都有着相似的地方，可抽象的维度，可通用的设计框架，比如订单的父子订单，订单的拆分，订单的正向和逆向，订单的基本信息，订单的商品信息，用户信息，状态信息，支付信息，以及围绕业务订单产生的清算订单，资金订单，营销订单，物流订单等等

对于订单流程不同的业务也有很大的差别，比如实物商品，收货就完结，还有一些比如家电还需要上门安装，就会衍生出服务单；虚拟商品也有支付成功就完结，也有需要上门服务的，比如上门保洁等，不同的业务会衍生出不同的子订单类型，也会有业务特点的订单流程。

订单的状态也是一个设计的关键点，不同的订单模型会有不同的状态枚举和变更，比如常见的“生成订单--待付款--待发货--待收货--完成”，如果是服务单的话，可能还包括待服务等服务状态。

今天我们从电商平台的电商订单模型，支付公司的纯支付订单模型来分析订单系统的设计、订单模型特点、母订单和子订单、订单拆分、订单的正向和逆向流程以及订单的上下游关系等。

2

电商订单模型

电商订单是最具有代表意义的，模型最复杂，种类最多；一般电商下单的业务流程是这样的——用户在平台挑选好了商品后去结算，然后填写订单信息，提交订单以后便生成了电商的购物订单，这时候订单是待支付状态，支付成功后变成待发货，商家发货后订单变成待收货，确认收货后订单就完结了，后面如果发生了退换货就有了订单的逆向流程，而且在订单的中间环节也可以出现订单取消造成订单终止，比如用户没有进行付款造成订单超时未支付而关闭。订单的业务流程如图2所示。

图2 订单业务流程

这是一个最简化的电商订单流程，实际的订单还有更复杂的场景，比如买了多个商家的商品就面临着拆单，就有了子单的概念；对于一个子单如果有多个商品来自不同的库房，那么还需要进行拆分成不同的物流单，如果一个物流单中的几个商品形态差异太大比如冰箱和图书，那么还需要拆成多个包裹；另外如果订单支付的时候用到了积分，优惠券等其他支付组合，那么支付单也会有多个，会有多个支付流程。这些关系如图3所示。

图3 单据之间的关系

（1）用户下单

用户下单时，订单信息从各个系统获取基础数据并进行校验，最后封装生成订单；订单为基础推动其他相关系统生成其他对应的单据。

（2）订单信息

订单需要记录一下相关维度的主要信息，基于业务模式的不同，可能需要增加其他辅助信息，这里主要介绍核心的订单信息内容：

谁买的：用户信息

买谁的：商家信息

买了什么：商品信息

钱怎么付的：支付信息

钱真的付了么：对账信息

发货了么：物流信息

上门安装了：服务信息

客诉了么：售后信息

破损了换一个吧：退换货信息

订单的旅程：订单日志

这些信息并不是存在一张数据表中，也不是简单的一对一的关系，各类信息可能需要存储在不同的表中，相互之间存在复杂的关联关系，如图4所示

图4 订单信息关系

（3）父子单

如果用户在购物车选择了多个商家的商品时，会将本次购买拆分成多个商家的子订单；第一次支付时会对总订单进行支付；如果因为各种原因中断了，那么后面再进行支付时则对每个店铺的子订单进行支付，就是到订单列表可以看到多个待支付的子订单。

这是按照店铺去拆，当然也可以基于业务需要基于其他模型对订单进行拆分，拆分订单的目的是基于业务需要或者其他需要而设计。假如购买了2个商家的ABC三个商品，总价是100元，平台优惠20元，其中A商品属于店铺1，B商品属于店铺2。订单拆分后的父子订单之间往往存在如表1所示的关系。

表1 父子订单数据关系

（4）优惠分摊

一个订单包含几个店铺的商品，每个店铺又有多个商品，而且在结算的时候又存在多个活动，有满减活动，优惠券，折扣等，如果这些优惠存在跨店铺情况，比如平台的满100减20，那么每个商家或者商品优惠了多少？退款的话怎么退，怎么与商家结算，财务如何记账；这时候我们就需要制定优惠的分摊策略，一般会把优惠拆分到sku上，也就是拆分到商品，因为用户可能会发起部分商品的退款，为了便于订单逆向处理以及优惠处理，拆分到商品更合适，也更公平。如表4-5中的优惠按照商品价格在订单商品总价的占比对优惠进行分摊

子单1的优惠分摊金额

=（优惠20）*（商品金额20）/（商品总价100）

=4

（5）订单状态

订单的状态记录了订单的变化以及流转，基于具体的业务需要设计订单的状态及变化逻辑，常见的订单状态包含——待付款，待发货，待收货，交易成功，已取消，售后中，订单关闭等，其流转关系如图5所示

图5 订单状态流转

（6）订单拆分

用户下单后，为了结算和售后方便，或者其他业务诉求，我们需要对订单进行拆分；一般影响拆单的因素有：平台的不同商家，发货仓库不同，品类特殊要求，物流因素，商品价值限制等

不同商家：单独结算，商家单独发货

不同发货仓库：北京的仓库，天津的仓库

包装要求：易碎的需要特殊包装，大件小件分开包装

物流因素：物流公司对包裹的体积和重量有要求

商品限价：比如海购，海关有限价等

所以拆单主要是两类，一类是下单时因为商家或者仓储问题拆成父订单和子订单，另一个是在发货时因为品类或者物流因素一个子订单拆成多个发货单，如图6所示

图6 订单拆分环节

（7）其他电商类型订单

还有一些电商订单形态，比如服务单，像保洁月嫂上门服务，家电上门安装等，会有一个业务订单，用户进行支付，然后业务单拆出来服务单，可能一个订单需要3个师傅上门服务，那么就需要拆分出3个服务单，服务单主要是来控制服务的履约。

（8）订单逆向

用户取消了订单，用户在支付成功后申请退款，用户收到货以后申请退货等等。

3

支付订单模型

还有另一个业务形态——三方支付公司的纯支付业务，包括收款、付款、商家提现等支付业务，这些业务也会生成订单，记录支付业务信息。但相对电商业务来说，支付业务的订单会有很多不同，例如没有实体商品，不需要发货收货，也就没有物流相关内容。我们将电商业务的订单关系移除业务订单以后剩下的部分适合与支付业务订单的关系表达，如图7所示

图7 支付订单单据之间的关系

基于支付公司的业务特点，将订单按照交易类型进行分类，比如收款订单，退款订单，清算订单，打款订单，营销订单，其他订单“鉴权认证，入网”等，所以订单范畴更广义。

（1）收款订单

三方支付的收款订单，其实就是商户平台的商品下单支付请求过来的支付请求，业务流流程如图8所示

图8 支付订单处理流程

（2）订单路由

我们知道一个支付公司会有很多的支付产品，也可能存在多个处理系统，从而不同的订单类型在进行流转时会请求不同的系统，订单路由就是基于订单类型和基本信息选择要交互处理的系统，比如请求什么交易系统，请求那个结算系统等

（3）订单模型

交易订单，交易订单是总订单，会基于账户，营销拆成子订单，如表2所示

表2 支付订单数据关系

（4）其他订单

其他类型订单，大同小异，像退款订单，分账订单等，这里就不在赘述了，后面在交易系统以及清结算和账务的设计介绍时还会涉及到其他类型的订单。

（5）订单服务

一个好的订单系统需要向上下游提供优质的订单服务，以及自身的订单处理业务，例如：

不同订单类型的创建服务

不同订单类型的查询服务

充，转，提，交易，退款等支付业务的回调通知服务

其他服务，比如补单，结算，订单分账等

（6）订单后台

在理解了业务模型并设计好了订单模型以及订单系统的能力以后，再设计订单的展示层和运营操作层的后台，会变得非常容易。只需要搞清楚需要提供什么样的功能给运营赋能，展示什么样的订单信息，基于实际业务需求设计即可，例如：

订单管理：基本的工具是订单列表，可以通过不同的条件查询不同的订单等

信息展示：展示订单的基本信息，商品信息，状态信息，支付信息等

系统关联：可以关联到支付系统查看支付详情，可以关联到用户中心查看用户信息等

换句话说，先有了业务再有了系统，先有了运营体系再有了系统的运营赋能，没必要追求现成的系统设计模板，可以尝试建立灵活的设计观念，基于业务模型设计出满足业务诉求的订单系统来。

推荐阅读