作为一个后端程序员，MVC三层架构的模式相信大家都不会陌生，三层分别从上而下排布，只能由上层调用下层。一般越往下层越通用，越上层越细节。
随着某些核心业务的访问量发展，通常我们需要去进行优化的措施，比如加缓存，加MQ，换数据源
当然，我们在做这些优化的时候，会将mq,mongodb等看成基础设施层。由此衍生出四层的架构，infrastructure里封装redis和mq的通用调用逻辑
这些优化的动作，通常不会改变原有的业务逻辑。但是为了做优化，我们会将它写在service层，比如：
问题点：
按道理来说，domain层是写业务逻辑的，优化不会涉及到业务逻辑的改动，但是却改动了domain层。由于domain层依赖了infrastucture的原因，导致业务依赖于具体的实现技术。所以，为了将业务与具体实现做分离，我们采用依赖倒置的手段去重构。
依赖倒置原则的包含如下的三层含义：
高层模块不依赖低层模块：那就可以在domain层定义存储的接口，如AARepository，但是不写具体的技术实现。
抽象不依赖细节：在domain层里，不依赖其他包的类，如用到数据存储时，直接调用domain的抽象接口即可。
高层通过依赖注入的方式，将基础设施的实现传到domain层中。
如此一来，我们的架构就不再是分层的结构(从上往下调用)。而是将抽象全部堆在domain层，将细节全部往application和infrastructure去推。而越抽象越稳定，所以通过这种做法能够有效减少业务的变更。
架构变成了一种从内而外的逻辑，越往内越抽象，越往外越细节。在北向网关，可以使用rest和dubbo去调用业务逻辑，南向网关可以将数据写到redis或mq。具体代码实现：
如下业务：发送课程成功了，要发送消息给设备IOT，发送MQ，更新缓存传统做法：
随着优化方案的不断增加，业务逻辑会越堆越多 六边形架构+EDA做法
//执行业务逻辑并发布发布课程事件当我们要做更新缓存操作的时候，实际上与业务逻辑没有什么关系，可以定义一个监听者去监听发布课程事件。这个SendCourseCacheHandler类要写到哪里呢?
所以这个类应该写在application层，其实是domain去调用application，所以说。。。这并不是分层架构。我们思考的时候是按抽象程度去判断应该写在哪里，而不是从上往下调用。
那这个监听者如何与业务结合起来呢?这时就发挥了application层的作用了，我们可以将application作为业务组装的逻辑。
如我们在业务开始之前，将监听者注册上去，这样在业务执行的时候，就可以回调这些监听者了
适合场景：
不适合场景：