订单业务解耦

如何解耦（按照什么标准解耦）？

eg: 有一支付成功的订单，已经发货，用户取消订单？ 这个场景从业务设计上讲如何解耦？

可能涉及的业务：订单业务、物流业务、支付业务(暂时只罗列这3个业务)

这些3个业务中可能发生的实际业务场景：

        1、用户取消订单---->订单业务---->订单服务；

         2、给用户（订单）退款---->支付业务--->支付服务；

         3、已发出货物原路返回---->物流业务-->物流服务（或者第三方物流服务）；

按照事物发展时间顺序排列上边3个业务场景应该是这样的：
        用户发起取消订单----->调用订单服务（取消订单成功）----->调用支付服务（发起退款成功）---->调用物流服务（回退货物）；

这样串行设计及服务调用(串行同步调用)存在的问题：

        1.调用链路长，链路越长越容易出错（技术实现等都需要环环相扣）；

        2.执行效率低下（降低了并发效率，增加了服务的负担）；

如何优化：

        1、将串行改为并行： 如何并行？？1、2、3同时并行，1失败了 2 和 3成功了 事务回滚或者补偿，貌似可以。如果1补偿还是失败了，岂不尴尬了；

        2、这个是什么业务？是个订单取消业务 ，退款和物流属于订单退款后引申出来的业务，属于从业务；因此先处理主业务，主业务处理成功后，并行处理2和3；将主从业务解耦，至于采用什么样的技术手段实现那就是另外一个问题了；