电商订单系统需要拆单吗？要聊这个话题，首先得从电商的架构说起，搞清楚电商交易系统的边界在哪？这样才能更清楚的知道在订单系统中拆单合不合适。
订单系统的边界在哪？
上面这图来自于网络上面关于京东的架构图，从整体的架构图，分为了三个阶段
第一个是加购阶段，就是从用户浏览商品到用户做出购物决策这个阶段，这个阶段主要是围绕着用户选商品，一般这个阶段都是由购物车承载，还没有生成订单，因此和订单系统关系不大。
第二个阶段下单阶段，是用户选择了商品进行下单进行支付，也就是订单系统所需要承接的事情，一般所说的订单系统也就是这个阶段所要承接的事情。
第三个阶段订单履约阶段，是指用户下完单支付完后，需要进行服务和商品的履约过程，一般由履约系统去承接，可能有些平台也会叫什么OMS订单管理系统。
本文所说的订单系统是否需要拆单，指的是在第二阶段的订单系统是否需要拆单。一般常规的业务来说，订单需要拆单的原因有如下一些情况
1、因为商品属于不同的供应商或者是商家
2、因为订单存在着不同的优惠，比如满赠
3、因为订单需要不同的履约，如有些是自提，有些是快递，有些是自己的配送体系等等
4、因为订单属于不同的平台，因为有些订单是给京东、淘宝等合作商进行引流等等
.......
讨论订单系统是否需要拆单？那订单系统在第二阶段这个环节是否需不需要拆单？
一个订单模型一般来说会分为主订单和子订单这种主子模型。
主订单主要是包含了用户的信息，下单的时间、订单的生命周期的状态......而子订单一般都是按照商品而来的，一般而然是一个商品对应一个子订单。
那我们来讨论下上面几种场景，看是否需要拆单
一、因为商品属于不同的供应商或者是商家
这里所说的商品是指同一SKU属于不同的供应商，比如用户购买了10斤平台，这10斤平台其中5斤为A供应商提供，另外5斤平台由B供应商提供。
如果是平台购销模式
这种情况实际上是用户向平台购买了10斤苹台，而平台向供应商A采购了5斤，向B供应商采购了5斤。是用户和平台之间发生了钱货转换的关系，平台和供应商A、B发生了钱货转换的关系？因此是用户与平台之间订立了一个订单的契约，在这种场景下，后续的售后服务应该由平台负责。
有人会说为了方便后续的结算建议由订单系统进行拆单，但个人认为这属于采购系统的范畴，是平台向不同的供应商发出采购订购，形成了采购契约，通过采购完成双方钱货转换的过程，和这种偏用户前台的订单系统没什么关系，个人认为这种情况订单系统不应该增加自身业务复杂性，而去实现其他系统事情，这属于边界不清，越往深做越鸡肋....
如果是平台代销模式
那实际上这10斤苹果是用户分别向供应商A采购了5斤，向B供应商采购了5斤，在这个过程中，平台只是一个中间撮合商的角色，在这种场景下，相当于是用户与供应商A、B发生了钱货转换的过程，与双方订立了订单契约，后续的售后的服务也是找供应商A和B，平台在这中间做协调，因此建议进行拆单，这样能更好的满足用户的知情权、售后、结算等一系列后续的事情。
二、因为订单存在着不同的优惠，比如满赠
这种情况的拆单一般是基于主商品和赠品进行一个拆分，比如买5斤苹果，送1斤苹果，也就是说这5斤苹果和1斤苹果是否需要进行拆分？这种情况建议还是订单系统进行拆单，会更好些。
三、因为订单需要不同的履约：如有些是自提，有些是快递，有些是自己的配送体系等等
这种情况是基于订单的不同的履约关系是否需要拆单，但本身这种履约关系，个人认为不应该由前台的订单系统去考虑，而应该由偏后台的履约系统去考虑，前台的订单系统更多还是扮演一种销售的角色，对交易后的订单进行存储，而对于如何进行配送？是通过用户自提还是通过第三方物流体系还是通过自营物流体系，是通过一个快递发出还是通过多个快递发出，这本身是属于履约的范畴，不应该把这种拆单的逻辑放在订单系统中，而应该下沉到履约系统里面，由履约系统根据订单的属性进行履约决策。
四、因为订单属于不同的平台：因为有些订单是给京东、淘宝等合作商进行引流等等
这种情况其实与第三种情况有点类似，其实也是一个履约的方式方法不同，因为这种是给第三方的平台进行引流，因此其履约肯定是由第三方进行履约，需要将订单信息推送给第三方平台，个人认为这也是属于履约的范畴，不应该进行在订单系统里面拆单。
总结对于因为采购关系、履约关系、结算关系等业务导致需要的拆单，不建议订单系统去承接，而应该由下沉到对应领域的系统去承接，这样更灵活，也更能接触到业务的第一线，而对于与用户的之间的物钱关系，如购销模式，满赠优惠等这种建议由订单系统进行拆单。