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

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

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

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

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

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

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

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

 

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

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

 

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

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

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

 

 

接下来我们需要聊一聊一个几乎被人快要被人聊烂掉的话题——订单号生成。无可厚非,在下单之前有一些业务逻辑其实是依赖订单号的。比如库存预占,甚至有一些特殊的促销计算和扣减也是需要订单号的。

 

关于订单号如何生成的话题,最烂大街的应该是某些机构不知道处于什么目的搞出来的“雪花算法”生成订单号。猿人工厂君就一句话放在这里——但凡面试时听到“雪花算法”生成订单ID的说法的,几乎就是那啥刚完事儿出来找工作的。

在真正的业务场景中,订单号是存在一些秘密的,各家电商系统在设计和考虑的时候都有所不同。但是以下两点应该是一致的。

 

第一,订单单号应该有它的特殊含义。看着订单号就大致能确定,订单是哪条业务线的订单。

第二,订单单号和用户存在一定的联系。为什么会这样?一个正常运转的电商系统,订单是很多的,在存储时,时需要采取策略的,比如分库分表,按用户分库分表肯定会是一个考虑的维度。至少在被考虑的维度上单个访问信息,可以快速定位路由。

我们可以通过下面这个例子来说明这个小秘密。

 

 

比如指定订单单号第三位和第四位代表某一类型业务,比如第三方订单,第789位为路由值。那么根据10020003400001这个订单号就能一目了然的看出,是什么订单,是哪个路由上的订单了。当然猿人君也就是举了个实际的例子,具体的规则嘛嘿嘿真是商业秘密了。

也许你会问,内部单号怎么唯一取得的?嘿嘿,最稳妥的还是数据库的方式来保障了,你会喷,性能上怎么行?比“xx算法差远了”。不过怎么来实现具体的细节,在具体实现时来体现,没有差的,只有不会设计的。

以上就是订单业务中,你必须要知道的两个小秘密了,这样的秘密其实还有很多噢。下一个章节,我们一起来聊一聊订单流程的那些事情了。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值