拆分订单服务是为了适应不同商品、库区及灵活的发货方式，我们将对订单状况进行更加细致的跟踪。同时向客户提供准确的商品预计发货时间和预计送达时间，使我们能更及时地兑现对客户的承诺。
业务上我们有自营及商家在平台上进行售卖商品，我们有自已的供应链和仓储系统，因此我们要适应这两种模式，同时不能推翻订单状态对整个业务生命周期的决定作用，还要兼顾售后和财务结算需求，我们一开始只有商家进驻业务这时各方可能考虑不能全盘，因此我们现在处处受困，一动就牵动全局，但是现在我们业务在做大，做全，因此调整还是要站在全盘的角度去考虑问题。
从原则上来说我们还是要业务解耦，并且增强未来需求的可扩展性、前瞻性、灵活性；
1、用户将商家加入购物袋，去结算，创建订单主数据；
购物袋有5件商品：
1、自营 鞋子 广州仓
2、自营 雨伞 湖北仓
3、商家A 冰箱
4、商家A 大电视
5、商家B 垃圾桶
创建完订单后，用户的订单主数据有1个订单，5件商品；没有任何拆单逻辑；在没有流入OMS之前，可以取消订单；一旦到OMS拆单中，状态为“审核”不可取消订单；
此时，用户展示的就是下单时原原本本下单的数据；
2、订单主数据流入OMS自动拆单系统；
异步通知OMS对订单主数据进行拆分，拿到订单号后，OMS根据自动规则进行拆分：
A、商家发货的按商家拆单，自营的根据订单发货地址及商品所在的仓库及库存拆单；拆单后的订单状态为：“待发货”；
B、没有库存的商品需要拆单，有库存的可先发货；
其他规则不细说
自动拆单后订单根据规则拆分成4个订单:
订单1 自营 鞋子 广州仓 发货；
订单2、自营 雨伞 湖北仓发货；
订单3、商家A 冰箱 大电视；
订单4、商家B 垃圾桶;
系统异步拆单后，OMS维护主数据订单与子单之间的关系，回写到订单，订单库中就有4个订单，同时告知用户前端，你的订单因为XXXX原因，为了方面你跟踪，我们拆分了订单，订单的状态为“待发货”，此时用户展示有4个订单；
3、根据不同的平台，分流到进行发货；
由上面拆分后的订单可以看出，订单1，订单2均为自营的，因此自营订单可以流入到WMS系统，仓库根据入库单进行发货，那么此时自营的订单1，发了1个包裹，订单1就有了包裹信息了，并且订单状态更新为“已发货”，订单2也是如此；
（如果是订单1和订单2在同一仓库，那么可能会进行同一个包裹发货，此时，订单1，订单2对应一个物流包裹）订单3，订单4 分别由商家A、商家B进行发货，商家A因为有大件的冰箱和大电视，需要分2个包裹进行发货，那么商家此时可以根据发货的不同商品对应的包裹信息进行2次拆单的操作。
2次拆单后订单根据发货包裹情况分成5个订单:
订单1 自营 鞋子 广州仓 发货；
订单2、自营 雨伞 湖北仓发货；
订单3、商家A 冰箱
订单4、商家A大电视；
订单5、商家B 垃圾桶;
商家ERP进行发货后，包裹信息有了，并且订单状态更新为“已发货”；
此时，用户前端可以看到5个订单，对应5个包裹信息，整个业务流程还是根据每个子单的状态进行衔接和流转。
至于财务需要的数据，可以在2次拆单并且确认收货后的状态数据上，做一中间层进行清洗，按商家、档期（订单上不管自营还是商家都有商家ID，订单商品上有档期ID）行拆分即满足结算的需求；
至此大体思路比较清晰，业务系统解耦：
服务化：主要是处理核心交易流程（成单、支付、取消），和用户支付过程，拆单逻辑原理在订单上同步处理，理论上如果不处理拆单逻辑，肯定性能有所提高；
OMS：订单管理系统，处理核心的自动拆单流程，维护主数据订单与子单之间的关系，有拆单规则配置，处理2次拆单按实际包裹拆单，并且回写订单库，所有订单的拆分合并核心业务都在此系统上处理，上对订单服务化，下接商家ERP和WMS，同时以后还要支持扩展用户按最快发货方式，用户手动拆单，已经在“发货”状态的订单不能拆分；
商家ERP：接受OMS的商家订单，承接商家订单后台的发货功能，需要调整为可以根据商品按批次发货，并且通知OMS，OMS根据实际发包情况进行2次拆分；
WMS：接受OMS的入仓出库单，并且根据仓库实际操作情况发包裹，如果有拆包或者合包的过程，通知OMS进行2次拆单，如果没有，那么自动拆单的订单会挂上包裹信息；
前端用户展示：
1、成单时，用户看到一个总订单，如果未进入OMS进行拆单，可以进行取消（因为OMS异步返回时间也是非常短，因此可以不考虑主单取消的情况）；
2、自动拆单后，用户会看到因为某些原因主订单被拆分，分别跟踪；
3、如果有2次拆单的情况，用户会看到订单再次被拆分，分别跟踪，单独对拆分的订单也就是对应到包裹进行确认收货；
售后、客服：可以根据拆分后子订单进行售后；
财务：可以在2次拆单并且确认收货后的状态数据上，做一中间层进行清洗，按商家、档期（订单上不管自营还是商家都有商家ID，订单商品上有档期ID）行拆分即满足结算的需求。
边界定义清晰，剩下的就是具体各子系统之间业务交互的具体实现，包括正常流程、和异常流程的考虑。全盘梳理及重新设计肯定是要大决心去推翻原来的东西，但是，如果设计和规划不合理，后面的扩展性很差，那工作量将不可想象，业务模型不正确的情况下，最关键的数据模型落地后是无法扭转过来的，请三思。
参考其他电商的一些拆单规则：
1. 您的订单中含有不可以同时打包配送的商品（高价值商品、大件商品、食品、危险品如香水等不可以和其他商品一起打包配送），系统将自动拆分订单；
2. 您的订单中的包裹重量超重，体积超大，商品数量超量，系统将自动拆分订单；
3. 您的订单中部分商品可以随时发货，其他商品没有库存或者暂时没有上市需要等待货源，等待时间超过10天仍没有发货，系统将自动拆分订单；
4. 您的订单中商品超过了预计发货期，系统将在第二天的晚间自动拆分订单，将可以发货的商品先行发货；
5. 您的订单中商品需要从不同库房发出，系统将自动拆分订单；
6. 您的订单中商品其中一个在订购时库存显示只有一个，如果同时有多个订单订购，该商品需要等系统的分配，系统将自动拆分订单；
7. 您的订单中包含了入驻卖家的商品（卖家独立配送）和平台负责配送的商品，系统将自动拆分订单