⑴订单系统作为一个业务子系统，在电商、零售、餐饮、教育、医疗saas系统中都非常常见。
⑵只要平台存在交易行为，那么必然逃不开订单系统，因为最终都需要通过创建订单，并支付，从而完成交易。
⑶由于订单系统的高出现频率，且不同业务的订单设计思路大同小异，所以我们可以把它作为一个底层系统进行抽象，建立一套订单的设计模型，便于我们快速应用到各个业务系统之中。
⑷订单作为电商最复杂的核心系统（或者称之模块，它建立其他系统模块之上。
⑸包括但不限于商品、优惠券、会员、营销活动、地址信息、积分、运费、购物车、支付、发收货等模块，都和订单息息相关，任何一个模块的改动，都可能影响到订单。不夸张的说，订单是交易平台最核心的子系统。
⑹订单包含的信息：
⑺从用户端（买家角度看，电商平台的订单流转中间状态一般有如下大状态：
⑻待付款：当用户提交订单后，支付之前，都属于待付款状态，商家端也是待付款状态。
⑼待发货：当用户完成支付后，订单状态变更为待发货，商家端也同步更新为“待发货”状态。
⑽待收货：当商家在后台确认发货后，订单状态在买家端的显示就会变成“待收货”状态，在卖家端会显示“已发货”，这里两边的展示会有一个区别。
⑾假如买家收到货一直不点确认，那么一般平台会有一个周期（淘宝是天，天后系统自动确认收货，变更为交易成功。
⑿退款中：一共两种情况会导致订单变更为“退款中”的状态。
⒀交易完成：一共有两种情况会导致订单变更为”交易成功“
⒁交易关闭：一共有种情况会出现“交易关闭”
⒂关于订单中的优惠分摊
⒃为什么要考虑优惠分摊，如果下单的时候使用了某种优惠活动，当订单进行部分退款的时候，我们肯定不能给买家直接退商品的原价，这样对卖家的损失就很大了。
⒄因此在订单生成时，就会针对使用优惠活动的商品计算优惠分摊。
⒅我们举个最简单的例子，买家购买了一个商品A元，一个商品B元，提交订单时参与了满减的促销活动，那么最后支付了元。
⒆假如买家收到货后觉得A不满意，申请退款，卖家同意后且完成退款流程后，应该退给A多少呢？
⒇A的退款金额=*/（+=.元（保留位小数点
⒈他并不能收到元，因为假如他收到了元，相当于最终用了元买到了B，这是存在漏洞的。
⒉再举个更复杂的案例：这个案例涉及到平台跨店促销优惠、店铺促销优惠、优惠券优惠券
⒊买家购买了个商品A元（甲店、个商品B元（甲店、个商品C元（乙店。
⒋提交订单时，参与甲店的满减的促销活动，同时还参与了平台满减的促销活动，此外还使用了一张元的平台代金券。
⒌那么根据优先级首先A+B的商品享受甲店的活动后变成了（+-=元，然后A+B+C继续参与平台的活动后变成了（+-=元，最终使用一张平台代金券后支付（-=元，即最终需支付元。
⒍即依次按照活动>活动>代金券的优先级进行参与。
⒎假设退款时，是无法退还代金券的，那么在订单生成时，我们来计算下每一层优惠分摊之后，A、B、C的可退金额是多少：
⒏第一层：活动分摊后
⒐商品A=-/（+*=.元
⒑商品B=-/（+*=.元
⒒第二层：活动分摊后
⒓商品A=.-/*.=.元
⒔商品B=.-/*.=.元
⒕商品C=-/*=.元
⒖注释：.+.+=元
⒗第三层：代金券分摊后
⒘商品A=.-／*.=.元
⒙商品B=.-/*.=.元
⒚商品C=.-/*.=.元
⒛注释：.+.+.=元
①所以经过优先级从高到底的三层优惠分摊后，A最终的实际可退金额为.元，B为.元，C为.元
②在电商平台中，只要有购物车功能，就会出现买家跨店购买商品的情况。
③比如一笔订单买了甲店的商品A一件，买了乙店的商品B一件，对于买家来说，他只是下了一笔订单；但是对平台来说，需要把A的订单信息推送给甲店，把B的订单信息推送给乙店，这就需要对买家的订单进行拆单。
④另外对于提交给甲店的订单来说，如果订单包含多个商品A、B、C，可能还会涉及到发货单的拆单，比如A、B一起发货，C单独发货。