当前位置: 首页 > 创领中心 > 网络优化

六边形架构和分层架构的区别

  • 网络优化
  • 2024-11-14

作为一个后端程序员,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作为业务组装的逻辑。

如咱们在业务开局之前,将监听者注册下来,这样在业务口头的时刻,就可以回调这些监听者了

适宜场景:

不适宜场景:

  • 关注微信

本网站的文章部分内容可能来源于网络和网友发布,仅供大家学习与参考,如有侵权,请联系站长进行删除处理,不代表本网站立场,转载联系作者并注明出处:https://www.clwxseo.com/wangluoyouhua/4888.html

猜你喜欢

热门资讯

关注我们

微信公众号