雁过留声，人过留名；互联网业务呢，那就留下订单吧；订单是个在常见不过的业务概念了，我们去淘宝买东西，点外卖，充话费，买会员，都会得到一个订单，最直接的意义就是订单记录了我们的业务凭证，买了什么，付了多少钱，平台交付了么，发货了么等，今天我们就详细分析下订单系统的设计。
01、基于业务设计订单
互联网产品肯定是先有了业务再有了系统，而不是先有了系统再有了业务；很多业务都实现了线上化，那么在互联网形态下的众多业务模型衍生出了众多的订单模型，比如电子商户的订单模型，实物订单和虚拟订单，支付交易的订单模型，清结算的订单模型，外卖的订单模型等等。
其实无论什么样的业务，订单作为业务的记录凭证都有着相似的地方，可抽象的维度，可通用的设计框架，比如订单的父子订单，订单的拆分，订单的正向和逆向，订单的基本信息，订单的商品信息，用户信息，状态信息，支付信息，以及围绕业务订单产生的清算订单，资金订单，营销订单，物流订单等等。
对于订单流程不同的业务也有很大的差别，比如实物商品，普通收货就完结，还有一些比如家电还需要上门安装，就会衍生出服务单；虚拟商品也有支付成功就完结，也有需要上门服务的，比如上门按摩等，不同的业务会衍生出不同的子订单类型，也会有业务特点的订单流程，这个大家可以认真思考一下。
订单的状态也是一个设计的关键点，不同的订单模型会有不同的状态枚举和变更，比如常见的“生成订单–待付款–待发货–待收货–完成”，如果是服务单的话，可能还包括待服务等个性化状态
订单难点
状态变更：都有哪些状态，状态间如何流转
库存扣减：什么时候锁定库存，扣减库存，释放库存
订单金额计算：商品价格，优惠等，应该支付多少钱呢
优惠分摊，订单拆单等
今天我们从电商平台的订单模型，支付公司的订单模型来分析订单系统的设计，订单模型如何；总订单和子订单，如何拆单，订单的正向和逆向流程，订单的上下游服务。
02、电商订单模型
电商订单应该是最具有代表意义的，也是最复杂模型的，种类最多的；用户在平台挑选好了商品后，去结算，然后填写订单信息，提交后便生成了电商的购买订单，这时候订单是待支付状态，支付成功后变成待发货，商家发货后订单变成待收货，确认收货后订单就完结了。
这就是一个最简化的电商订单流程，实际的订单还有更复杂的场景，比如买了多个商家的商品就面临着拆单，就有了子单的概念；对于一个子单如果有多个商品来自不同的库房，那么还需要进行拆分成不同的物流单，如果一个物流单中的几个商品形态差异太大比如冰箱和图书，那么还需要拆成多个包裹单；另外如果订单支付的时候用到了积分，优惠券等其他支付组合，那么支付单也会有多个，会有多个支付流程。
用户下单
用户下单时，订单信息在各个系统之间校验和流转，最后封装生成订单。
订单信息
订单需要记录哪些信息呢，谁买的，买了什么，付钱了么，发货了么等等。
父子单
如果用户在购物车选择了多个商家的商品时，会将本次购买拆分成多个商家的子订单；第一次支付时会对总订单进行订单的支付；如果因为各种原因中断了，那么后面再进行支付时则对每个店铺的子订单进行支付，就是到订单列表可以看到多个待支付的子订单；这是按照店铺去拆，当然也可以基于业务需要进行其他模型下对订单进行拆分，拆分订单的目的是基于业务需要或者其他需要而设计。
优惠分摊
一个订单包含几个店铺的商品，每个店铺又有多个商品，而且在结算的时候又存在多个活动，有满减活动，优惠券，折扣等，如果这些优惠存在跨店铺情况，比如平台的满100减20，那么每个商家或者商品优惠了多少？退款的话怎么退，怎么与商家结算，财务如何记账；这时候我们就需要制定优惠的分摊策略了，一般会把优惠拆分到sku上，也就是拆分到商品，因为用户可能会发起部分商品的退款，为了便于订单逆向处理以及优惠处理，拆分到商品更合适，也更公平。
分摊规则
订单活动x优惠金额*该商品总价/参与活动的商品总价。
例如订单中有甲，乙两个店铺的A，B，C，D，E5个商品，A和D参与满200减40的活动1，商品B和C参加满100减10的活动2，另外还是用了一张100元的平台券。
订单状态
订单的状态记录了业务的变化以及流转，基于具体的业务需要设计订单的状态及变化逻辑，待付款，待发货，待收货，交易成功，已取消，售后中，订单关闭等。
订单拆分
用户下单后，为了结算和售后方便，或者其他业务诉求，我们需要对订单进行拆分；一般影响拆单的因素有：平台的不同商家，发货仓库不同，品类特殊要求，物流因素，商品价值限制等：
- 不同商家：单独结算，商家单独发货
- 不同发货仓库
- 品类包装要求：易碎的需要特殊包装，大件小件分开包装
- 物流因素：物流公司对包裹的体积和重量有要求
- 商品限价：比如海购，海关有限价
所以拆单主要是两类，一类是下单时因为商家或者仓储问题拆成父订单和子订单，另一个是在发货时因为品类或者物流因素一个子订单拆成多个发货单。
其他类型订单
还有一些订单形态，比如服务单，像保洁月嫂上门服务，家电上门安装等，会有一个业务单，用户进行支付，然后业务单拆出来服务单，可能一个订单需要3个师傅上门服务，那么就需要拆分出3个服务单，服务单主要是来控制服务的履约。
订单逆向
用户取消了订单，用户在支付成功后申请退款，用户收到货以后申请退货等等，这里就不在赘述了。
03、支付订单模型
还有另一个业务形态那就是三方支付公司的纯支付业务，收款，打款，商家结算等也会存在订单，记录支付业务，相对电商来说支付业务的订单会简单一些，毕竟没有实体商品，不需要发货收货也就没有物流。
基于支付公司的业务特点，我们会将订单按照交易类型进行分类，比如收款订单，退款订单，清算订单，打款订单，营销订单，其他订单“鉴权认证，入网”等，所以订单范畴更广义，基本体现了订单的业务记录职能，相比较支付业务的交易系统，订单算是第二核心系统了。
收款订单
三方支付的收款订单，其实就是商户平台的商品下单支付请求过来的支付请求，业务流流程图如下。
订单路由
我们知道一个支付公司会有很多的支付产品，也可能存在多个处理系统，那么不同的订单类型在进行流转时会请求不同的系统，那么订单路由就是基于订单类型和基本信息选择要交互处理的系统，比如请求什么交易系统，请求那个结算系统等。
订单状态
订单模型
交易订单，交易订单是总订单，会基于账户，营销拆成子订单。
资金订单
营销订单
其他订单
其他类型订单，大同小异，像退款订单，分账订单等，这里就不在赘述了，后面再交易系统以及清结算和账务的设计介绍时还会涉及到其他类型的订单。
订单服务
一个好的订单系统需要向上下游提供优质的订单服务，以及自身的订单处理业务，即向外提供什么样的服务接口。
不同订单类型的创建服务接口
不同订单类型的查询服务接口
充，转，提，交易，退款等支付业务的回调通知服务
其他服务接口，比如补单，结算，订单分账等
订单后台
在理解了业务模型以后，设计好了订单模型以及订单系统的能力以后，订单后台只是展示层和运营操作层的设计，相对比较简单，提供什么样的运营赋能，展示什么样的订单信息基于实际业务需求设计即可。
比如：
订单管理：基本的需要有订单列表，可以通过不同的条件查询不同的订单。
信息展示：展示订单的基本信息，商品信息，状态信息，支付信息等。
系统关联：可以关联到支付系统查看支付详情，可以关联到用户中心查看用户信息等。
总而言之，先有了业务再有了系统，先有了运营体系再有了系统的运营赋能，不要一味的追求现成的系统设计模板，产品经理需要建立灵活的设计观念，基于业务模型设计出满足业务诉求的订单系统。
进一步交流可以加入学习群，与更多产品人探讨交流。
