1、商品业务
业务思想：
一般的订单业务设计：主要分为3part， 主订单表， 子订单表， 订单详情表。
图(1)
售前：拿货
售中：卖货
履约：给货
售后：退换
1，下单减库存，如唯品会，减30分钟，JD，减1天，天猫，减3天。
2，付款减库存，如时效性特别高的秒杀，很少见。
总结：何时减库存，最终的目的是要保障每个商品都能卖出去（卖方利益），每个人都能买到想要买的商品（买方利益），需要在买方与卖方之间权衡，现在大部分的做法就是下单减库存（保障你每个人都能买到-买方利益），但会有一定的时间限制（保障每个商品都能卖出去-卖方权益）。
关于下单时，订单信息+ 商品快照的使用
涉及领域 订单中心、商品中心
场景：
订单的逻辑的拆分：
根据以上的规则，订单逻辑上面应该按照这样的方式来拆分。
图(2)
根据以上的规则，订单逻辑上面应该按照这样的方式来拆分。
订单的金额拆分：
图(3)
这里会引入部分商品打折，部分商品搞活动，部分商品有优惠券，这种情况发生，基于这种考虑需要引入子订单的概念。
例子：营销那边有很多的优惠券和营销工具，商户可以通过营销系统的各种工具把各种优惠券派发到用户手上，怎么派发我们不管，用户手上就是一张买满500 赠送一本书的券，券A。
此时用户把sku1价值400的蛋糕（常价，非特价商品）和价值200的酒sku2(特价商品)，加入到购物车，此时用户sku1标注，买2件非特惠价的商品，可以打8折，用户就把sku3价值150的枕头加入到购物车。此时，sku1+sku3 总价打8折，sku1+sku2+sku3 8折后符合满赠，送了一本书价值0元。
同时，该用户是该店的老客户了，商城系统有积分抵扣的规则，目前该用户有200积分，按规则每10积分抵扣1毛钱，既能抵扣2块钱。
| 总订单： 支付金额638 金额：640 积分抵扣金额2块 运费0 |
子订单1： sku1 蛋糕 总价320 商品价格400 优惠类型：优惠8折（订单表关联到某优惠类型，这里的优惠类型是优惠8折） |
子订单2： sku2 酒 总价200 商品价格200 优惠类型： 特惠价（订单表关联到某优惠类型，这里的优惠类型是特价商品） |
子订单3： sku3 枕头 总价120 商品价格150 优惠类型：优惠8折（订单表关联到某优惠类型，这里是优惠8折） |
子订单4： sku4 书 总价0 商品价格0 优惠类型：赠品（订单表关联到某优惠类型，这里是满赠） |
|---|
优惠券的价值
是优惠，不是现金。
请注意电商领域通俗意义上的优惠券是指下单可以优惠金额的券，使用即作废。不是那种可以充值到账户的现金券，也不是可以使用多张的折扣券。
退款的时候优惠的金额怎么处理
如果不处理，那用户下单100+50-20优惠，如果全部退款则是退款150，很明显对商家造成营收上面的损失。
如果处理则按照”哪里优惠回哪里”的规则来处理：
- 如果是指定某件商品/某类商品的优惠券，那优惠金额肯定由该商品承担的。当退该商品，需减去优惠券金额。
- 如果是指定某些（分类、商户、活动等），那优惠金额分摊到符合资格的商品上。
- 如果是全店铺通用，那优惠金额分摊到每一个购买商品上。
分摊金额的算法有两种：
- 按照符合优惠券的商品金额进行均摊
- 按照订单剩余部分是否符合优惠券
举例：顾客购买了A商品1件90元，B商品1件30元，使用了一张优惠券满100元减20元。如果顾客想退款A商品：
- 按照算法1，提交退款的最多金额为90*(90+30-20)/(90+30)=75元。
- 按照算法2，因为商品B＜100元，则提交退款的最多金额为90-20=70元。
实际情况中方案A和B的金额，有高有低。如果由于特殊原因需要给用户多退，客服可在后台修改。
采用的是第一种，对用户比较公平，体验比较好。
常用的交易流程：
图(4)
我们项目现状需求的流程：
图(5)
上面的状态扭转时间是可以根据需要来调整，并设计job来做一定的自动补偿（job定时跑任务实现）和人工手动补偿（Oem页面手动触发补偿）的机制，实物商品取消订单，要考虑退款的时效性。
图(6)
对于目前项目现状的实现方案：
订单单品的思路：
mall_product_order + product_order作为订单主表（这2张表后面需要改造，可以分步进行）
| 字段名 | 类型 | 允许空值 | 默认值 | 是否主键 | 注释 |
| orderNo | 订单中心的OrderId | ||||
| customerId | 买家用户Id | ||||
| status | 订单状态 | ||||
| totalFee | 主订单金额 | ||||
| create_time | |||||
| update_time |
sub_product_order（字段待补充）
| 字段名 | 类型 | 允许空值 | 默认值 | 是否主键 | 注释 |
| orderNo | 订单中心的OrderId | ||||
| subOrderNo | 子订单Id | ||||
| totalFee | 订单金额 | ||||
| subOrderType | 子订单状态 | ||||
| 积分 | |||||
| 折扣 |
备注：子订单为母订单拆分出来的一个订单，子订单也含有多个商品，一个商品sku会有一个订单明细即sub_product_order_detail。
sub_product_order_detail(看是和sub_product_order 合并还是独立出来，字段待补充)
| 字段名 | 类型 | 允许空值 | 默认值 | 是否主键 | 注释 |
| subOrderNo | 子订单号 | ||||
| shopId | 商户Id | ||||
| goodId | 商品Id | ||||
| skuiId | 规格Id | ||||
| goods_version | 商品变更的历史版本号 | ||||
| totalFee | 商品金额 | ||||
| amount | 单商品sku数量 | ||||
| be_salse_status | 售后状态 | ||||
| 审核状态 | |||||
备注: goods_version 商品库存做版本化，除上架下架操作外，商品信息没做一次修改都会生成一个版本。
举个例子：比如订单有A 2X10元 B 1X20元 C 3X30元 的商品， 目前对 B C 商品进行退款， 那么sub_product_order 有 A B C 3个单品的单， 对B C（BC单独发起还是合并发起都可以） 发起退款，就是按原来的全量退款来做，这样退款和订单就分离开来了，原来的退款逻辑不变。
思路还不成熟，需要考虑。
涉及修改的逻辑：
1：下单逻辑需要再调整，需要对购物车List商品进行拆单，insert到子订单表中。
2：
参考文章：
B2C自营商城的订单设计方案 https://zhuanlan.zhihu.com/p/26470223?utm_source=wechat_session&utm_medium=social
大众点评订单系统分库分表实践 https://zhuanlan.zhihu.com/p/24036067?utm_source=wechat_session&utm_medium=social
B2C自营电商APP的优惠券设计方案(上篇) https://zhuanlan.zhihu.com/p/25083430
B2C自营商城的商品设计方案：http://www.woshipm.com/pd/628034.html
来源：oschina
链接：https://my.oschina.net/u/1187675/blog/1618297