淘宝订单的设计逻辑

　　最近在做订单方面的需求，由于我们平台是综合类平台，电商、OTA、虚拟业务都有，所以对订单设计的通用性要求比较高，因此体验了一下强大的淘宝是如何做的，算是自我总结。
　　场景一：使用平台通用购物津贴（满2。1减2元）同时购买两家店铺的商品
　　一家商品金额2元，一家商品金额1元。
　　结果如下图：
　　图一：合并提交订单但未支付
　　图二：合并提交订单且未支付
　　图三：合并提交订单后取消订单
　　图四：合并提交订单后去付款
　　结合图一和图四可知：订单是无法选择合并支付选择框的（该按钮已置灰），但是点其中任意一个付款按钮时，要求两个订单必须同时支付，因为这两个订单共同使用了平台购物津贴。
　　由图三可知：这两个订单必须一起取消，不能单独取消，原因也是因为两个订单共同使用了购物津贴导致。
　　由图四可知：这两个订单虽然必须一起支付，但是付完款之后就互相独立，互不影响。
　　场景二：看购物津贴的退款
　　图五：图二订单其中一个退款
　　图六：图二订单全部完成退款
　　由此可以知道淘宝的购物津贴是按照每个商家的商品金额（和运费无关）按照比例分摊的，而且其购物津贴是可以部分退和部分使用的。
　　场景三：多个订单一起下单
　　有些订单必须和其他订单一起下单，不能单独购买和退款，例如火车票（门票、飞机票）中的保险，订单提交未付款时订单列表如下图：
　　图七：购买火车票时
　　购买保险看起来和和其他订单列表没什么区别，但是可以看到列表中是没有付款按钮的（这个地方应该是淘宝设计上一个不好的地方），因为他们把付款按钮放到了火车票的订单详情页，该详情页是包含保险信息的。
　　而保险的订单详情页中是没有付款按钮的，只有订单信息。
　　如下图所示：
　　图八：火车票订单详情
　　图九：保险订单详情
　　下面一个景点门票的本质逻辑和火车票是一样的，而且把付款按钮放在了订单列表中，这样更便于用户操作，如下图：
　　图十：门票订单（下单时购买了一种保险）
　　结合这两个门票订单和火车票订单可以看出：保险也都是以独立订单的角色存在，这样应该是为了便于结算，因为门票、火车票、保险的供应商都是不同的。
　　而且我又在景点门票订单中同时选择了两份保险，如果这两个保险由不同的保险公司提供，那么应该共有3笔订单：门票订单、保险1订单、保险2订单，结果的确如此，如下图：
　　图十一：门票订单（下单时购买了二种保险）
　　可以得出结论：
　　淘宝做为综合性平台，有很多商家入驻为了便于结算订单均是在商家维度上进行主订单拆分，每个主订单下会根据商家的不同商品进行子订单拆分；订单列表是在商家维度展示的，也就是主订单。
　　为了满足平台型通用的购物津贴，淘宝在独立拆单后会存在订单关联，这些订单在付款前必须一起支付才能共同享用平台津贴，共同取消才能释放购物津贴；付款后，各个商家的订单互相独立可单独退款。如果没有共同使用平台购物津贴而一起提交订单的，淘宝就是按照商家维度去拆单，各个店铺的优惠独立计算，支付和取消、退款时也不存在关联关系。订单结构应该有3层。
　　购物津贴是根据每个商家的商品销售总金额按照比例分摊的，平台的津贴优惠在每个子订单上都是单独的字段记录。退款时，如果退某个商家的订单，那么可以将该订单中使用的购物津贴部分退还用户（对平台来说是被薅羊毛）。
　　对于类似火车票和保险这样的订单，拆单规则应该都是通用的，因为我们可以在订单列表中看到订单是独立显示的而且也是在商家维度进行拆单的，但是订单之间建立了强关联关系，有些订单不能独立操作，必须依附于其他订单进行状态变更，这个是由商品是否可独立购买和独立退款决定的（例如保险）。这种订单的下单场景本质上和购物车订单一样，但是在商品上又增加了一步逻辑校验。
　　淘宝的订单列表是不能按照业务类型去筛选订单的，只能按照订单状态，那是应该是因为淘宝还是主打电商，在满足电商场景需求的同时去支持其他业务类型的下单，例如：OTA业务。
　　门票和火车票、保险的商家都是不一样的，猜测飞猪的发展方向应该是往OTA平台方向发展，等同于淘宝、天猫这样的电商平台。
　　只是表面上体验了一下淘宝的订单，个人做出以上总结，至于到底该如何设计订单，需要产品经理们根据各自平台的不同特性去设计，例如京东和淘宝就有所差别。如有不对，欢迎指正，也期待一起探讨。
　　另外关于共同使用购物津贴的订单曾猜想：用户一起下单后直接进入收银台支付的话支付金额肯定是扣除购物津贴后的，如未支付进入订单列表各个订单也是互相独立的，订单金额应该是按照不使用购物津贴来计算的，用户使用合并支付功能时如果满足购物津贴的使用条件，会从待支付总金额中减掉。
　　我认为这样用户使用购物津贴会更灵活，去支付订单时体验也会更好。
　　但淘宝没这么做，肯定有自己的道理，推测为：
　　会涉及到订单金额的二次计算，这样虽然用户体验上会更好，但是不符合订单的计算规则。订单提交后会生成快照，这个快照信息生成后就不会再变更，是双方交易的凭证，以后商品信息变更都不会影响该笔订单信息，避免纠纷也便于以后的订单数据统计。
　　可能觉得这样的功能对于订单支付成功转化率来说并没有提升吧，所以没有投入成本去开发，毕竟涉及到快照信息的保存开发成本还是挺大的。