有一个观点已经被说烂了：使用 MQ 可以帮助业务系统解耦。
想法很简单，在业务状态流转时，如果没有 MQ，那么其它系统想要知道状态变了，那就需要核心流程系统去主动做通知。
比如电商系统里订单从创建到处理中状态切换了，客服系统需要知道，风控系统需要知道，用户系统也需要知道。
一个典型的依赖关系
这里的通知通过 RPC 来进行，下游系统需要的数据可以在这次 RPC 里携带上，也可以在请求的时候让下游系统自己去查。
下游系统增加的时候，核心业务的代码也需要修改，比如新做了一个积分系统，现在订单状态流转积分系统也想知道。
下游增加新系统时
核心系统需要不停地增加调用关系来迎合下游新增的业务方需求。这些边边角角的计算逻辑和订单系统本身没啥关系，但是因为下游需要拿到这些数据，我们就需要自己用 RPC 去调用下游的接口。这确实不太合理。
当下游系统发生事故时，很容易让核心系统也跟着一起躺了：
下游炸了上游也得炸
这种情况下，核心系统对下游系统的依赖主要是因为 core system mentions downstream system，和单系统内的耦合是一样的。
解决这种耦合的最简单的方法，在单模块的情况是用依赖反转，在分布式场景下，就是引入消息队列：
用消息队列解除上游对下游的依赖
在修改之后，每次订单流转只要将 domain event 发送到消息队列就可以了。下游系统有计算需求，自己去订阅相关的 topic 即可。
有了消息队列时下游增加新系统
讲到这里就结束，那就是童话故事了。在一开始的图中，我们存在的依赖是双向的：
双向依赖
核心系统依赖下游系统是因为调用关系，下游系统依赖核心系统是因为下游系统要使用核心系统的数据。
我们使用 MQ 只是解开了单个方向上的依赖，核心系统没有对下游系统的调用了。
有一个方向的依赖被解除了
这样下游系统在崩溃的时候，也就不太容易影响到核心系统的稳定性。
隐式依赖导致事故
但下游系统对核心系统的数据依赖是不可能解除的，如果核心系统修改了产生 domain event 的代码，还是会导致下游系统出故障，很多情况下出故障都是一死死一片：
上游的 domain event 出问题的时候
大点的互联网公司经常是核心服务一做重构，下游服务哀鸿遍野。
数据依赖对于核心系统来说并不是一个可以显式看到的依赖，所以对于核心系统来说，这是外部对我的隐式依赖。
看不见的依赖是很可怕的，所有人都会慢慢地逐渐忽视它，直到事故发生的那一天。
核心系统对下游系统重新建立依赖
虽然梦做的很好，但核心系统在服务用户的过程中，往往也是要给用户返回一些实时计算的数据的，这部分数据从哪里来？
很多就是从下游计算系统来，比如说，我的订单流转系统，现在要在用户积分达到某个条件的时候，做一些特殊逻辑。
随着业务的发展，我们最初解除掉的依赖，又重新被建立了。
回到原点
环形依赖回来了！这下两个系统可能又会变成你挂我也挂的情况了。兜兜转转，我们重新回到了原点。
