得物主子订单模型
主子订单模型
在展开讨论之前，先需要给出一个比较清晰的定义，主子订单是什么？
如何界定主订单
主订单承载用户购买行为中【某逻辑聚合维度内所有相关 SKUS】的动作和流转。
逻辑聚合取决于具体的业务场景，接下来会根据得物的业务模型，大致分析【逻辑聚合】到底是什么逻辑抽象，从表现上来看，主订单是一个或者一些子订单的聚合。
如何界定子订单
子订单承载用户购买行为中 SKU 的动作和流转。
所有电商都支持 SKU 维度的取消,退货行为，这也是消费者的合法权利，为此需要一种模型去承接用户购买行为中 SKU 的动作和流转。
依据订单现有的订单数据结构和模型，在不做大改动的情况下，使用子订单去承载用户购买行为中 SKU 的动作和流转。
所以我们需要明确回答-子订单到底是什么？
以某个项目为例：在球鞋定制时，从表面上看，在一次创建订单的过程中，其费用项主要有三类：
- 实体商品
- 定制化服务
- 运费服务
- 方案 1：是不是可以建立三个子订单来完成上述逻辑的表达
- 方案 2：建立一个子订单来完成上述逻辑的表达
- 方案 3：建立两个子订单来完成上述逻辑的表达
观察以上三个元素-实体商品，定制化服务，运费服务：
- 共同点是：它们都是付费的一个费用项，他们属于一个实体或者服务商品
- 差异点是：实体商品，定制化服务可以被单独售卖，但是运费服务是必然不会被单独售卖。
一个子订单 = 有且仅有一个可被售卖的商品 + 多个不可被售卖的商品
不可被售卖的商品在一个订单中通过费用项去表达，而不是通过订单去表达。比如一个实体商品订单的构成是：
sub_order_no + delivery_fee
在此基础上清晰的解释了一个子订单是什么。
现状，未来，架构趋势
【得物主子订单模型】结合得物的业务模式，订单侧现已有主子订单的概念，并且在历史交易数据中，都是一个主订单有且仅有一个子订单。
得物现今主流交易模型中，用户下单时，存在以下特点：
- 只可购买一个商品
- 商品数量不可选择，默认商品数量是 1
- 由于平台存在质检流程，从物流上看，买卖家无法直接交易，发货和退货都必须经过平台中转
- 未来一段时间内，多地开仓之前，平台只有一个真实履约仓库，发货和退货的中转仓库只有一个
- 一次提交订单产生一笔主订单
- 一次提交订单单只包含一个子订单；主订单包含子订单；一个子订单包含一种 SKU
- 一次提交订单只产生一个支付单
- 一次提交订单只产生一笔物流单
- 平台在整个交易流程中仍是强介入，在一段时间内不太可能开放商家与买家直接交易。
- 合并支付或购物车需求会日益紧迫，旧模型中，用户购买多个商品支付多笔运费的方式急需改善。
- 随着订单量的增长，多地开仓将是大势所趋。物流有效合并将是趋势。
平台在整个交易流程中强介入，与传统电商模型有比较大的不同，淘宝，京东的交易提议中，店铺的概念很强。在以下几个方面买家都可以清晰的感知到店铺的存在：
文章图片
所以淘宝和京东的订单大部分是店铺为单位。主子订单比较好切分，假如同一个店铺下的所有购买行为作为主订单，单类 SKU 作为子订单，那么主子订单模型大致如下：
ps: 一种 SKU 在同一个店铺下购买 M 份，当 M 大于 2 时，到底是以一个子订单还是 M 个子订单去承单待考量。
文章图片
但是得物的交易模型中，商家，平台，买家三方的作用都很强，平台作为链接买家和卖家的纽带，质检和中转卖家售卖和买家退货，导致了订单模型不可以简单的按照店铺为基本切分单位。借鉴于电商平台主订单的直观对外展示，部分子订单的聚合标准大致有以下几个：
文章图片
如果基于以上模型去考虑，那么影响子订单聚合的指标大概有：
文章图片
如果基于以上的业务模型进行分析，进一步进行逻辑抽象，将【仓库】【商家】【购买渠道】等等一系列统一抽象成【指标】，那么系统的逻辑模型大致如下：M 个子订单聚合成 N 个主订单。
文章图片
综上所述: 主订单是对用户提交订单成功后展示结果的抽象。
文/juven
关注得物技术，做最潮技术人！
推荐阅读
- 【019|【019 当时发生了什么】好事近·偶得主子
- SU通车（阿里巴巴托管教你如何提升店铺订单）
- 微商怎么推广（订单才不会中断？）
- Java 实现订单未支付超时自动取消
- 【建议收藏】2021年底最新安卓面经分析，最终入职得物！
- 猫主子
- 【系】微信小程序云开发实战坚果商城-前端之订单实现
- 【系】微信小程序云开发实战坚果商城-云开发之订单品数据实现
- 简单1招发朋友圈便订单源源不断（学会这个再也不愁没销量！）
- 店铺流量订单为何频频下降（1688分销采集模式可以解决）