【得物技术】主子订单模型

主子订单模型：

在展开讨论之前，先需要给出一个比较清晰的定义，主子订单是什么？

如何界定主订单

主订单承载用户购买行为中【某逻辑聚合维度内所有相关 SKUS】的动作和流转。

逻辑聚合取决于具体的业务场景，接下来会根据得物的业务模型，大致分析【逻辑聚合】到底是什么逻辑抽象，从表现上来看，主订单是一个或者一些子订单的聚合。

如何界定子订单：

子订单承载用户购买行为中 SKU 的动作和流转

所有电商都支持 SKU 维度的取消,退货行为，这也是消费者的合法权利，为此需要一种模型去承接用户购买行为中 SKU 的动作和流转。

依据订单现有的订单数据结构和模型，在不做大改动的情况下，使用子订单去承载用户购买行为中 SKU 的动作和流转。

所以我们需要明确回答-子订单到底是什么？

以某个项目为例：在球鞋定制时，从表面上看，在一次创建订单的过程中，其费用项主要有三类：

• 实体商品

• 定制化服务

• 运费服务

在不考虑现有模型的基础上，发散性的思考，可能有以下三种方案：

• 方案 1：是不是可以建立三个子订单来完成上述逻辑的表达；

• 方案 2：建立一个子订单来完成上述逻辑的表达；

• 方案 3：建立两个子订单来完成上述逻辑的表达；

直觉告诉我们，应该采用方案 3：建立两个子订单来完成上述逻辑的表达；但是为什么？任何方案都会有一个逻辑表达，两个订单的方案更优的逻辑表述是什么？

观察以上三个元素-实体商品，定制化服务，运费服务：

• 共同点是：它们都是付费的一个费用项，他们属于一个实体或者服务商品

• 差异点是：实体商品，定制化服务可以被单独售卖，但是运费服务是必然不会被单独售卖。

按照这个抽象得出的结论是：

一个子订单 = 有且仅有一个可被售卖的商品 + 多个不可被售卖的商品

不可被售卖的商品在一个订单中通过费用项去表达，而不是通过订单去表达。比如一个实体商品订单的构成是：

sub_order_no + delivery_fee

在此基础上清晰的解释了一个子订单是什么。

现状，未来，架构趋势：

结合得物的业务模式，订单侧现已有主子订单的概念，并且在历史交易数据中，都是一个主订单有且仅有一个子订单。

得物现今主流交易模型中，用户下单时，存在以下特点：

• 只可购买一个商品

• 商品数量不可选择，默认商品数量是 1

• 由于平台存在质检流程，从物流上看，买卖家无法直接交易，发货和退货都必须经过平台中转

• 未来一段时间内，多地开仓之前，平台只有一个真实履约仓库，发货和退货的中转仓库只有一个

根据以上主流交易场景，使用以下模型几乎可以解决用户下单时所遇到的所有问题：

• 一次提交订单产生一笔主订单

• 一次提交订单单只包含一个子订单；主订单包含子订单；一个子订单包含一种 SKU

• 一次提交订单只产生一个支付单

• 一次提交订单只产生一笔物流单

但没有任何一家公司是一层不变的，未来，得物肯定会整合已有的业务模型，同时也会提出新的业务述求，大胆预测业务将朝以下几个方向发展：

• 平台在整个交易流程中仍是强介入，在一段时间内不太可能开放商家与买家直接交易。

• 合并支付或购物车需求会日益紧迫，旧模型中，用户购买多个商品支付多笔运费的方式急需改善。

• 随着订单量的增长，多地开仓将是大势所趋。物流有效合并将是趋势。

为此旧模型需要一定程度上的扩充才可以继续支撑业务发展。首先先大致分析下以上业务发展趋势：

平台在整个交易流程中强介入，与传统电商模型有比较大的不同，淘宝，京东的交易提议中，店铺的概念很强。在以下几个方面买家都可以清晰的感知到店铺的存在：

所以淘宝和京东的订单大部分是店铺为单位。主子订单比较好切分，假如同一个店铺下的所有购买行为作为主订单，单类 SKU 作为子订单，那么主子订单模型大致如下：

ps: 一种 SKU 在同一个店铺下购买 M 份，当 M 大于 2 时，到底是以一个子订单还是 M 个子订单去承单待考量。

但是得物的交易模型中，商家，平台，买家三方的作用都很强，平台作为链接买家和卖家的纽带，质检和中转卖家售卖和买家退货，导致了订单模型不可以简单的按照店铺为基本切分单位。借鉴于电商平台主订单的直观对外展示，部分子订单的聚合标准大致有以下几个：

如果基于以上模型去考虑，那么影响子订单聚合的指标大概有：

如果基于以上的业务模型进行分析，进一步进行逻辑抽象，

将【仓库】【商家】【购买渠道】等等一系列统一抽象成【指标】，

那么系统的逻辑模型大致如下：M 个子订单聚合成 N 个主订单

综上所述: 主订单是对用户提交订单成功后展示结果的抽象。

文/juven

关注得物技术，做最潮技术人！