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

作为一个后端程序员，MVC三层架构的模式相信大家都不会陌生，三层分别从上而下排布，只能由上层调用下层。一般越往下层越通用，越上层越细节。

网站建设哪家好，找创新互联公司！专注于网页设计、网站建设、微信开发、小程序定制开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了象山免费建站欢迎大家使用！

随着某些核心业务的访问量发展，通常我们需要去进行优化的措施，比如加缓存，加MQ，换数据源

  • 缓存可选redis，memcache
  • MQ可选kafka，rocketmq，rabbitmq
  • 数据源可选：mysql，mongodb，elasticsearch复制代码

当然，我们在做这些优化的时候，会将mq,mongodb等看成基础设施层。 由此衍生出四层的架构，infrastructure里封装redis和mq的通用调用逻辑

这些优化的动作，通常不会改变原有的业务逻辑。但是为了做优化，我们会将它写在service层，比如：

  • 执行成功就发个MQ
  • 执行某个事件的时候，同步一下缓存
  • 依赖关系为，domain依赖infrastructure

问题点：

按道理来说，domain层是写业务逻辑的，优化不会涉及到业务逻辑的改动，但是却改动了domain层。由于domain层依赖了infrastucture的原因，导致业务依赖于具体的实现技术。所以，为了将业务与具体实现做分离，我们采用依赖倒置的手段去重构。

依赖倒置原则的包含如下的三层含义：

  • 高层模块不应该依赖低层模块，两者都应该依赖其抽象
  • 抽象不应该依赖细节
  • 细节应该依赖抽象

高层模块不依赖低层模块：那就可以在domain层定义存储的接口，如AARepository，但是不写具体的技术实现。

抽象不依赖细节：在domain层里，不依赖其他包的类，如用到数据存储时，直接调用domain的抽象接口即可。

高层通过依赖注入的方式，将基础设施的实现传到domain层中。

如此一来，我们的架构就不再是分层的结构(从上往下调用)。而是将抽象全部堆在domain层，将细节全部往application和infrastructure去推。而越抽象越稳定，所以通过这种做法能够有效减少业务的变更。

架构变成了一种从内而外的逻辑，越往内越抽象，越往外越细节。在北向网关，可以使用rest和dubbo去调用业务逻辑，南向网关可以将数据写到redis或mq。具体代码实现：

 
 
 
    
  
  
  
  1. 如下业务：发送课程成功了，要发送消息给设备IOT，发送MQ，更新缓存
    2.

传统做法：

 
 
 
    
  
  
  
  1. void sendCourse(){
    2. 
  
  
  
  2.     //执行业务逻辑
    3. 
  
  
  
  3.  //发送消息给设备IOT
    4. 
  
  
  
  4.  //发送MQ
    5. 
  
  
  
  5.  //更新缓存
    6. 
  
  
  
  6. }
    7.

随着优化方案的不断增加，业务逻辑会越堆越多 六边形架构+EDA做法

 
 
 
    
  
  
  
  1. public SendCourseService sendCourseService{
    2. 
  
  
  
  2.  void sendCourse(SendCourseCommand command){
    3. 
  
  
  
  3.      //执行业务逻辑并发布发布课程事件
    4. 
  
  
  
  4.  eventBus.push(SendCourseEvent())
    5. 
  
  
  
  5.  } 
    6. 
  
  
  
  6. }
    7.

当我们要做更新缓存操作的时候，实际上与业务逻辑没有什么关系，可以定义一个监听者去监听发布课程事件。这个SendCourseCacheHandler类要写到哪里呢?

 
 
 
    
  
  
  
  1. public class SendCourseCacheHandler{
    2. 
  
  
  
  2.  
    3. 
  
  
  
  3.  private Jedis jedis;
    4. 
  
  
  
  4.  public void deleteCache(SendCourseEvent event){
    5. 
  
  
  
  5.  //删除缓存
    6. 
  
  
  
  6.  }
    7. 
  
  
  
  7. }
    8.
  • 按照抽象往domain写，细节往外写的划分，写到基础设施层不合适，因为与业务强相关。
  • 写到domain不合适，因为与redis这些具体实现强相关。

所以这个类应该写在application层，其实是domain去调用application，所以说。。。这并不是分层架构。我们思考的时候是按抽象程度去判断应该写在哪里，而不是从上往下调用。

那这个监听者如何与业务结合起来呢?这时就发挥了application层的作用了，我们可以将application作为业务组装的逻辑。

如我们在业务开始之前，将监听者注册上去，这样在业务执行的时候，就可以回调这些监听者了

 
 
 
    
  
  
  
  1. public class CourseAppService{
    2. 
  
  
  
  2.  
    3. 
  
  
  
  3.  private SendCourseCacheHandler sendCourseCacheHandler;
    4. 
  
  
  
  4.  private SendCourseMQHandler sendCourseMQHandler;
    5. 
  
  
  
  5.  private SendCourseService sendCourseService;
    6. 
  
  
  
  6.  private EventBus eventBus;
    7. 
  
  
  
  7.  public void sendCourse(SendCourseCommand command){
    8. 
  
  
  
  8.  //删除缓存
    9. 
  
  
  
  9.  eventBus.register(sendCourseCacheHandler);
    10. 
  
  
  
  10.  //发MQ
    11. 
  
  
  
  11.  eventBus.register(sendCourseMQHandler);
    12. 
  
  
  
  12.  sendCourseService.sendCourse(command);
    13. 
  
  
  
  13.  }
    14. 
  
  
  
  14. }
    15.

适合场景：

  • 读/写比较大的场景
  • 对查询实时性要求不高的场景
  • 内部状态改变会触发各种数据的同步，如课程完成，课程发布等等等等。。。
  • 外部实现可替换，如mq可以随意替换实现

不适合场景：

  • 只有简单CRUD的业务，没有重的业务逻辑，不适合搞那么复杂，因为没必要抽出domain层

标题名称：六边形架构和分层架构的区别
文章位置：http://www.shufengxianlan.com/qtweb/news12/532562.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

云服务器知识

同城分类信息

响应式网站设计　　 　绵阳电信服务器托管　　 　南充服务器托管　　 　网站收录　　 　古巴雪茄　　 　蜀锦在线　　 　成都网站建设　　 　成都网站推广　　 　品牌设计　　 　成都400电话申请　　 　眉山电信机房　　 　整合营销　　 　四川成都seo网站优化　　 　成都商城网站建设　　 　服务器租用　　 　微商城开发　　 　网络营销推广　　 　成都导视系统设计　　 　石膏隔墙　　 　h5页面制作