得物主子订单模型

网豹

每个电商公司订单系统大概率都会有主子订单的概念，而主子订单与业务模式和业务特征紧密相连，得物的订单设计是什么样子？基于什么样子的背景？我们为什么做了这样的设计？这个设计是不是与未来公司发展想契合？?也许这边文章大致可以找到答案。主子订单模型在展开讨论之前，先需要给出一个比较清晰的定义，主子订单是什么？如何界定主订单主订单承载用户购买行为中【某逻辑聚合维度内所有相关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得物技术? 关注我们，做最潮技术人！