猿设计23——真电商之订单中的那些秘密-CSDN博客

本文链接：https://blog.csdn.net/hzldds2019/article/details/107958957

经过前面一段时间的学习，相信你对类目、属性、商品、促销、库存、购物车的业务和设计有了一定的了解。上一章节我们也讨论了订单的实体信息。

似乎应该去讨论下单的流程问题了，不过在这之前，还有一下事情需要来解决。今天是订单的第三个章节，猿人工厂君打算和你聊一聊订单那些你必须知道的小秘密。

猿设计同样是一个原创系列文章，帮助你从一个只是具备一些技术名词的小白猿人，开始掌握一些行业内通用的设计系统方法，提高你需求挖掘、需求分析、系统分析和设计的能力，完成属于你的能力聚变，更多精彩内容，敬请大家关注公主号猿人工厂获取！

提起订单有哪些你必须知道的秘密，也许你会说，猿人工厂君又在卖关子了，其实今天要讲的内容，对于经验十分丰富的朋友来讲，实在算不得什么，但是离开了这些东西，电商就真的不好意思称为电商了。

我们先来说说提交订单的一个场景。说用户A一次性买了很多东西，分别属于不同的商家，提交订单之后，却只有一个订单，那么个订单就会带来一些问题？订单中的货物由谁来配送呢？

相信细心的朋友已经发现了，猿人工厂君在抽取实体的时候，给每一个订单相关的实体分配了一个parentOrderId的属性，从字面含义都能猜到，是父单号的意思。那么很明显，一个订单很可能会被拆分开来噢。

是哒，必须给拆了，要不然商家怎么去发货啊？大家都用一个订单号，然后各种去处理相应的商品发货问题？很明显一个订单会被拆成多个订单了。那么猿人工厂君再提一个问题——什么时候拆？

有的朋友说，下单的时候生成多个订单，每个订单包含一个商家的商品不就好了？这样子做只是理论上可以，而且暴露你毫无经验的实锤了。下单时就拆开，那么请问支付怎么办？用户挨个去支付吗？这样做的后果很明显让客户更加麻烦——注意，我说的是客户不再提的是用户（给钱了才叫客户）。

客户觉得麻烦之后，自然可能临时改变主意，不支付某些商品。或者直接找到平台优惠的一些漏洞，先给优惠拿到手，剩下的你们自己玩耍吧。所以什么时候拆——支付之后拆（除了货到付款）！客户给完钱了，确定买了，然后需要生产履约了，拆开它就好了。

那么第二个问题可以开始讨论了——按什么业务规则去拆分?第一个维度，按商家，大家都知道了。不按商家拆分，根本没法玩儿。那么第二个维度是什么呢？注意到storeId没有？按仓库拆分。仓库和地址是有关系的，其实在下单的时候，还涉及到一个库存的问题——从近的地方发货，自然成本低啊，要不建立仓库的意义何在？

这两个维度其实基本上地球人都知道的。那么猿人工厂君再说说你可能不知道的了——从运输的角度出发，不同的货物可能寻找不同的供应商比较合适。那么就是按物流供应商来拆分也会是一个考量。

还有没有其它的因素？当然有，比如一个商家搞了活动，优惠力度比较大，订单金额也比较大。有的人买完东西看着一笔订单比较大，可能反悔退货的。或者说他仅仅是看中了某一个货物，又想利用漏洞来套取优惠，那么在设计拆单的时候可以考虑按金额拆、按优惠拆等等策略了。甚至在生产上搞点儿小手段——赠品后发也是有的噢。好了，我们来梳理下拆单的逻辑吧。