作为后端程序员，相信大家都对MVC的三层架构模型不陌生。三层从上到下排列，只有上层才能调用下层。一般来说，层级越低越笼统，层级越高越细化。随着接入某些核心业务的发展，我们通常需要采取优化措施，比如加缓存，加MQ，改变数据源缓存可以选择redis，memcacheMQ可以选择kafka，rocketmq，rabbitmq数据源可选：mysql,mongodb,elasticsearchcopycode当然我们在做这些优化的时候会把mq,mongodb等作为基础设施层。由此衍生出四层架构，将redis、mq的通用调用逻辑等优化动作封装在基础设施中，通常不会改变原有的业务逻辑。但是为了优化，我们会写在服务层，比如：执行成功的时候发送一个MQ执行事件的时候，同步缓存依赖as，领域依赖于基础设施对于写业务逻辑，优化不涉及修改业务逻辑，但更改到域层。因为领域层依赖于基础设施，业务依赖于具体的实现技术。因此，为了将业务与具体实现分离，我们采用依赖倒置的方式进行重构。依赖倒置原则包括以下三层含义：高层模块不应该依赖低层模块，两者都应该依赖于它们的抽象抽象不应该依赖于细节细节应该依赖于抽象高层模块不依赖onlow-levelmodules：那么可以在domain层定义存储接口，比如AARepository，但是不写具体的技术实现。抽象不依赖细节：在领域层，不依赖其他包中的类。比如在使用数据存储时，可以直接调用领域的抽象接口。上层通过依赖注入将基础设施的实现传递给领域层。这样，我们的架构就不再是层级结构（称为自上而下）。相反，所有的抽象都堆叠在领域层，所有的细节都被推送到应用程序和基础设施。越抽象越稳定，所以这种方式可以有效减少业务变化。架构从里到外变成了一个逻辑，往里走的越抽象，往外走的细节越多。北向网关可以使用rest和dubbo调用业务逻辑，南向网关可以写数据到redis或者mq。具体代码实现：如下业务：发送课程成功后，需要向设备IOT发送消息，发送MQ，更新缓存传统方法：voidsendCourse(){//执行业务逻辑//发送消息给设备IOT//发送MQ//更新缓存}随着优化方案的不断增加，业务逻辑会越堆越多。六边形架构+EDA实践publicSendCourseServicesendCourseService{voidsendCourse(SendCourseCommandcommand){//执行业务逻辑并发布课程事件eventBus.push(SendCourseEvent())}}当我们要更新缓存操作时，其实和业务逻辑无关。我们可以定义一个监听器来监听发布课程的事件。这个SendCourseCacheHandler类应该写在哪里呢？publicclassSendCourseCacheHandler{privateJedisjedis;publicvoiddeleteCache(SendCourseEventevent){//deletecache}}不宜写入基础设施层，因为与业务强相关。不宜写domain，因为它与redis的具体实现强相关。所以这个类应该写在应用层。实际上，域调用应用程序，就是这么说的。..这不是分层架构。我们在思考的时候，是根据抽象的层次来判断应该写在哪里，而不是自上而下的调用。那么这个监听器如何与业务结合呢？这时候应用层就发挥作用了，我们可以把应用作为业务组装的逻辑。如我们在业务开始之前，将监听者注册上去，这样在业务执行的时候，就可以回调这些监听者了publicclassCourseAppService{privateSendCourseCacheHandlersendCourseCacheHandler;privateSendCourseMQHandlersendCourseMQHandler;privateSendCourseServicesendCourseService;privateEventBuseventBus;publicvoidsendCourse(SendCourseCommandcommand){//删除缓存eventBus.register(sendCourseCacheHandler);//SendMQeventBus.register(sendCourseMQHandler);sendCourseService.sendCourse(command);}}Applicablescenarios:scenarioswithrelativelylargeread/writerequirementsandlowreal-timequeryrequirements,internalstatechangeswilltriggervariousdataSynchronization,suchascoursecompletion,coursereleaseandsoonandsoforth...Theexternalimplementationcanbereplaced,suchasmqcanbereplacedatwill.Theimplementationisnotsuitableforthescenario:onlysimpleCRUDbusiness,noheavybusinesslogic,notsuitableforsuchcomplicated,becausethereisnoneedtoextractthedomainlayer
