关于下单我有话要说......
对于存在订单流程的系统,下单是举足轻重的一步...... 差一步掉进深渊(扣绩效)无法生还~
一份订单在生成到交易结束的整个生命周期里
在之前都会让产品和研发绞尽脑汁~
可现在有没有发现随随便便打开一个小程序都能下单
啊这,时代在变化.......
本文简述下 下单的相关流程,仅供初步参考
STEP1:
用户在点击商品详情页的时候,后台会调用商品服务查询当前商品详情,查询用户服务信息
【商品详情】:通常返回商品的图片链接、规格参数、数量、限购信息、价格等(关联表设计)
【用户服务】:返回用户相关信息如 白黑名单信息
如果一切没有异常,用户可以点击购买或者加入购物车到提交订单的页面
STEP2:
提交订单的页面需要返回啥? 订单金额、用户是否拥有红包/优惠券、限购商品用户已购买信息等
如果用户拥有优惠券/红包,需要返回当前商品满足的用户所拥有优惠券/红包由用户选择。
有些产品设计系统时会让研发实现 用户如果拥有红包/优惠券 自动抵扣的功能~
这个由上面一步稍微改造下即可--注意后台代码商品价格的计算(钱是重点)
楼主之前做过五种类型的优惠券组合抵扣来计算商品最终价格的逻辑.......真是一地鸡毛
提交之后生成待支付订单入库,此时会涉及到
①商品库存的预扣减(通常为锁定库存,并非真正扣减库存)
②订单超时支付的任务,在超时的同时释放库存和更改订单状态的逻辑
③IM聊天消息和推送任务会推送给商家,让商家沟通你及时买买买~(如果有这个功能)
④有些产品会让研发实现订单拆分~ (关于订单拆分的逻辑在支付之前和支付之后实现,对于支付的流程没有太多的影响,总金额和对应拆分订单的金额是正确的即可)
STEP3:
支付,到了 付钱这关键的一步啦~ 现在支付这块坑的已经越来越少了
集成支付宝、微信、银联的开源项目都已经很多,更何况一些有自研能力的公司自己开发
业务侧主要需要关注商品抵扣的金额,红包的扣减
如果涉及到未发货退款 ,退款金额是商品折扣的金额以及判断优惠券/红包时候需要退回,还有库存处理、积分处理等功能,具体需求可以视自己产品可定~
支付成功后,订单状态和商品的改变是一个重点~此后就会通知商家备货和发货了--
此时又涉及到 订单状态的改变 比如 已支付、待发货、已发货、已收获、已评价等.
.....没完没了
STEP4:
图上还有很多未提及的服务,例如售后服务、物流服务、会员服务等
但下单的流程都大同小异~
针对下单流程,涉及到
超买超卖 、秒杀、分布式事务
都需要结合具体业务逐一解决~
(工资到位,一切都好说)