在v1.1的版本之前，走取购的订单模块应付的业务场景比较简单，具体表现在所有的商品购买最终只会生成1笔订单，不过随着产品的需求升级，系统需要对接第三方渠道的商品，不仅仅是自营，例如还有网易严选，唯品会等等。

对于新版本的要求，由于商品的来源渠道不同，促销方式和物流等亦不相同，不可能跟之前的版本一样处理成为1笔订单了，自然第一反应想到的肯定是拆单，但具体到方案落实上呢？

为了响应本次需求，我还特意参考了其他主流电商网站的做法，主要是当当，京东。发现它们的需求场景跟我们大致一样，都是同有自营商品之外，另外有其他渠道/入驻店铺的商品，客户端用户则可以自由组合进行统一下单。

而对于拆单的时机，上面的两个网站处理方式就稍显不同了：

简单来说，对于京东而言，你在购物车里存放了来自包含自营和其他渠道的商品，当你立即下单时，这时系统会产生一个订单号（也就是后来的父订单），该订单号下关联了所有渠道的商品，结算也是打包一起。只有当用户真正支付成功过后，该笔订单才会真正进入拆单系统，按照渠道的不同拆分成为子订单，但还是会关联到最开始的父订单号。

再来看看当当的，前面的流程还是一样，不同的地方在于，当用户请求下单后，后台系统就已经根据前端传入的商品列表，再按照渠道进行拆单，无任何异常的话订单表会生成几条平级的渠道订单。

综合评估了下，我采用了当当做法，其中有一大部分原因也是为了兼容最开始的数据库设计。因为在最开始的订单相关表的设计时，就没有去考虑父子订单的关系，所以也就没有一个类似parent_id的字段去记录当前订单的父订单是谁，其二是在前台做订单记录查询时也会遇到兼容性问题，同时还有根据id查询订单详情之类的接口改动也很大。

还有一个原因就是，当时的1.1版本已经上线一段时间了，这时候再去动基础模块的数据结构风险也很大，因为我实现拆单的方法有两种，而且第二种方案其实改动相对来说很小，有兼容以前的功能设计，何乐不为呢?

当然，我们这次拆单功能也较为基础，有些电商有比这个更为复杂的拆单流程，大家如果有兴趣可以了解下。