环球观点：电商订单系统产品架构_超详解析订单系统架构

订单系统作为一个业务子系统，在电商、零售、餐饮、教育、医疗saas系统中都非常常见。

(相关资料图)

只要平台存在交易行为，那么必然逃不开订单系统，因为最终都需要通过创建订单，并支付，从而完成交易。

由于订单系统的高出现频率，且不同业务的订单设计思路大同小异，所以我们可以把它作为一个底层系统进行抽象，建立一套订单的设计模型，便于我们快速应用到各个业务系统之中。

订单系统架构

No. 1

以电商为例：

订单作为电商最复杂的核心系统（或者称之模块），它建立其他系统模块之上。

包括但不限于商品、优惠券、会员、营销活动、地址信息、积分、运费、购物车、支付、发收货等模块，都和订单息息相关，任何一个模块的改动，都可能影响到订单。不夸张的说，订单是交易平台最核心的子系统。

订单包含的信息：

电商订单系统架构：

因此做好订单管理，最重要的是覆盖的全面性、和极强的可扩展性。

订单系统模块拆分

No. 2

订单主要分：订单创建和订单管理两部分.

一、订单创建：

订单创建可以由C端用户、以及B端使用者发起创建，并在订单系统中生成。

订单创建的节点，在页面上的展示，就是提交订单页面点击“提交订单”按钮那一刻，订单就会被创建。

当然表面上看，点击“提交订单”就触发了订单创建，但背后，创建过程会调用前面所说的各个模块，并且夹杂了大量的逻辑判断。

提交订单页原型：

以下为订单生成的校验：

即在“提交订单”那一刻，会进行多个信息的逻辑判断

配送信息：配送方式和配送地址。

需判断是否填写了配送方式和地址；（如果是外卖）配送地址是否超过配送范围；

商品

需判断商品是否是上架状态； 商品是否售罄； 商品库存是否小于订单中的商品数量；（如有赠品赠送）需判断赠品是否库存不足；

运费

选择收获地址后，会根据后台的运费模版自动进行运费计算，并回显在【提交订单】页； 提交订单时需要校验运费信息是否变动；

促销活动

需判断当前该用户、该订单商品适用的所有促销活动。促销活动一般分平台级、店铺级2个层级

平台级：针对平台内商品的促销活动； 店铺级：针对店铺内商品的促销活动。

当然一般这类活动还有一些限制条件，比如

订单满多少金额才可以参与 只限一定等级的会员 只限某些类目，或指定商品才可以参与 如果同时满足多个活动参与的条件，则只能参与优先级最高的活动；

等等，视促销活动数量和复杂度而定。

会员优惠

提交订单时需判断会员等级及相应优惠权益是否变动，需判断可用积分数量是否变动。

优惠券

需要判断优惠券是否已核销； 是否已过期； 是否在适用时段内； 是否已被使用等。

一旦提交订单后，则订单即完成创建，这个时候订单模块还会发起指令要求其他模块进行相应的配合：

订单中的商品库存需要在商品模块中进行冻结处理 订单中使用的优惠券需要在优惠券模块中进行状态变更 订单中使用的促销活动权利应该标记为已使用该权利 订单中扣减的积分应该在用户积分中进行扣减等

当然对于外卖而言，还需要在提交订单的时候对店铺是否在休息时间、店铺是否开启该配送方式、订单价格是否满足起送价等各种情况进行确定，如存在变动则给出用户相应提示。

二、订单管理

当订单被创建后，即进入订单管理阶段。

C端页面：

B端的订单管理页：

订单轮转流程：

关于订单状态

从用户端（买家）角度看，电商平台的订单流转中间状态一般有如下6大状态：

1）待付款：当用户提交订单后，支付之前，都属于待付款状态，商家端也是待付款状态。

2）待发货：当用户完成支付后，订单状态变更为待发货，商家端也同步更新为“待发货”状态。

3）待收货：当商家在后台确认发货后，订单状态在买家端的显示就会变成“待收货”状态，在卖家端会显示“已发货”，这里两边的展示会有一个区别。

假如买家收到货一直不点确认，那么一般平台会有一个周期（淘宝是14天），14天后系统自动确认收货，变更为交易成功。

4）退款中：一共两种情况会导致订单变更为“退款中”的状态。

是在“待收货”状态下，即商家已经发货后，买家进行退款操作，那么订单状态会直接变成退款中； 是在“待发货“状态下，买家取消订单／卖家操作全额退款，则进入退款中状态。 是买家确认收货后，申请退款，则进入”退款中“状态，一般电商平台都支持确认收货后7天无理由退货

5）交易完成：一共有两种情况会导致订单变更为”交易成功“

是用户确认收货； 是买家申请部分退款，退款流程结束，且剩余商品确认收货后，订单变更为“交易成功”。

6）交易关闭：一共有3种情况会出现“交易关闭”

是“交易成功”后发起全额退款，完成退款流程变更为“交易关闭”； 是在”待支付“的时候买家取消订单／订单超时过期）； 是“待发货”的时候买家申请退款，商家确认后订单变更为“交易关闭”。

关于订单中的优惠分摊

为什么要考虑优惠分摊，如果下单的时候使用了某种优惠活动，当订单进行部分退款的时候，我们肯定不能给买家直接退商品的原价，这样对卖家的损失就很大了。

因此在订单生成时，就会针对使用优惠活动的商品计算优惠分摊。

举例

我们举个最简单的例子，买家购买了一个商品A100元，一个商品B200元，提交订单时参与了满100减50的促销活动，那么最后支付了250元。

假如买家收到货后觉得A不满意，申请退款，卖家同意后且完成退款流程后，应该退给A多少呢？

A的退款金额=100*250/（100+200）=83.33元（保留2位小数点）

他并不能收到100元，因为假如他收到了100元，相当于最终用了150元买到了B，这是存在漏洞的。

再举个更复杂的案例：这个案例涉及到平台跨店促销优惠、店铺促销优惠、优惠券优惠券

举例

买家购买了1个商品A100元（甲店）、1个商品B200元（甲店）、1个商品C300元（乙店）。

提交订单时，参与甲店的满200减50的促销活动1，同时还参与了平台满200减100的促销活动2，此外还使用了一张150元的平台代金券。

那么根据优先级首先A+B的商品享受甲店的活动1后变成了（100+200-50）=250元，然后A+B+C继续参与平台的活动2后变成了（250+300-100）=450元，最终使用一张平台代金券后支付（450-150）=300元，即最终需支付300元。

即依次按照活动1>活动2>代金券的优先级进行参与。

假设退款时，是无法退还代金券的，那么在订单生成时，我们来计算下每一层优惠分摊之后，A、B、C的可退金额是多少：

第一层：活动1分摊后

商品A=100-50/（100+200）*100=83.33元

商品B=200-50/（100+200）*200=166.67元

商品C=300元

第二层：活动2分摊后

商品A=83.33-100/550*83.33=68.18元

商品B=166.67-100/550*166.67=136.37元

商品C=300-100/550*300=245.46元

注释：83.33+166.67+300=550元

第三层：代金券分摊后

商品A=68.18-150／450*68.18=45.45元

商品B=136.37-150/450*136.37=90.91元

商品C=245.46-150/450*245.46=163.64元

注释：68.18+136.37+245.46=450元

所以经过优先级从高到底的三层优惠分摊后，A最终的实际可退金额为45.45元，B为90.91元，C为163.64元

2、关于拆单

在电商平台中，只要有购物车功能，就会出现买家跨店购买商品的情况。

比如一笔订单买了甲店的商品A一件，买了乙店的商品B一件，对于买家来说，他只是下了一笔订单；但是对平台来说，需要把A的订单信息推送给甲店，把B的订单信息推送给乙店，这就需要对买家的订单进行拆单。

另外对于提交给甲店的订单来说，如果订单包含多个商品A、B、C，可能还会涉及到发货单的拆单，比如A、B一起发货，C单独发货。