📰 来源: 博客园
引言：那些年我们写过的“面条代码”
痛点场景： 你一定经历过这样的噩梦：系统最初用 MySQL 存储数据，后来为了性能要迁移到 MongoDB。结果你发现，业务代码里密密麻麻全是对 MySQL 驱动的直接调用。或者，老板突发奇想，要求把原本的 Web 页面功能，原封不动地搬到一个新的命令行工具（CLI）里，你却发现业务逻辑和 HTTP 的 Request / Response 对象死死绑定在一起。
“牵一发而动全身”，修改一行代码，整个系统崩溃。这是因为我们的核心业务逻辑被外部框架、数据库和 UI 强行“绑架”了。
解决方案： 这时候，六边形架构（Hexagonal Architecture） 闪亮登场。它的核心理念极其简单：将核心业务逻辑与外部依赖彻底隔离。它能让你的业务代码变得像插座一样通用，无论外接的是哪种数据库或哪个前端框架，核心系统都能从容应对。
概念拆解：餐厅后厨的生存哲学 (The "What" & "Why")
生活化类比：米其林餐厅的运作
别被“六边形”这个高大上的名字吓到，它其实也被称为端口与适配器模式（Ports and Adapters）。我们用“去餐厅点餐”来理解它：
想象一家顶级的米其林餐厅，它的核心竞争力是“后厨大厨的烹饪手艺”（核心业务逻辑）。
输入端（Driving）：大厨根本不在乎客人是通过服务员点餐、通过美团外卖下单，还是打电话预定。大厨只认一样东西：标准化的点餐单（输入端口 Input Port）。服务员和外卖App在这里就是输入适配器（Input Adapter），负责把各种乱七八糟的请求翻译成大厨能看懂的点餐单。
输入端（Driving）：大厨根本不在乎客人是通过服务员点餐、通过美团外卖下单，还是打电话预定。大厨只认一样东西：标准化的点餐单（输入端口 Input Port）。服务员和外卖App在这里就是输入适配器（Input Adapter），负责把各种乱七八糟的请求翻译成大厨能看懂的点餐单。
输出端（Driven）：大厨做菜需要土豆。他不会自己跑去菜市场买，他只会对采购员下达指令：“给我拿两个土豆”（输出端口 Output Port）。至于采购员是从门口超市买的，还是从远洋货轮上空运的（输出适配器 Output Adapter，如 MySQL、Redis、第三方 API），大厨毫不关心。
输出端（Driven）：大厨做菜需要土豆。他不会自己跑去菜市场买，他只会对采购员下达指令：“给我拿两个土豆”（输出端口 Output Port）。至于采购员是从门口超市买的，还是从远洋货轮上空运的（输出适配器 Output Adapter，如 MySQL、Redis、第三方 API），大厨毫不关心。
工作流图解：洋葱般的结构
如果画个图，六边形架构就像一个洋葱，分为内、中、外三层：
最内层（Domain）：纯粹的业务实体和规则（大厨的手艺）。这里没有任何外部框架的代码。
最内层（Domain）：纯粹的业务实体和规则（大厨的手艺）。这里没有任何外部框架的代码。
中间层（Ports）：接口定义层（点餐单和采购单）。它规定了外部如何与核心交互，以及核心如何向外部要数据。
中间层（Ports）：接口定义层（点餐单和采购单）。它规定了外部如何与核心交互，以及核心如何向外部要数据。
最外层（Adapters）：具体的实现（服务员、外卖App、采购员）。比如 Spring Boot 控制器、REST API、MyBatis Mapper。
最外层（Adapters）：具体的实现（服务员、外卖App、采购员）。比如 Spring Boot 控制器、REST API、MyBatis Mapper。
核心原则：依赖只能从外向内！
🔗 原文链接: 点击阅读原文
文章评论