六边形架构端口与适配器模式

可视化演示

动态演示六边形架构端口与适配器模式的核心机制，通过全局/局部/动态/静态四种模式展示关键概念与交互流程。

1. 架构起源：后厨为什么站在中间

一家法餐厅最值钱的是后厨的菜谱，而不是某个牌子的燃气灶或冰箱。顾客在哪里吃饭不重要，重要的是后厨能稳定出餐。软件也一样：业务规则是菜谱，框架和外部系统是炉灶和冰箱。把菜谱和炉灶焊死，换一个牌子的炉灶就要重写菜谱，这是传统分层架构最让人头疼的地方。

六边形架构正是为了解决这个痛点而生。Alistair Cockburn 在大量企业级系统开发中发现，UI 和数据库并不像传统分层图里画的那样“高高在上”或“垫在底下”，它们只是围绕业务核心的普通访客。于是他用六边形表示核心，把外部系统画在六边形外面，避免视觉上产生“上层/下层”的等级暗示。

每条边都代表一个对外交互的通道。核心既不认识 HTTP，也不认识 SQL，它只通过通道上的“端口”对外表达“我需要什么”和“我能提供什么”。端口是一组约定，真正把外部世界和约定对接起来的，是后续要讲的适配器。

回到餐厅比喻：六边形不是让你真的修六个门，而是提醒你——门可以多也可以少，但所有门都必须对着外面的世界，而不是对着后厨的炉灶。门里门外互不干扰，才能保证后厨的稳定性。

2. 端口：给业务核心留下的门

后厨必须有两个口：一个是“点单口”，顾客的菜名从这里进来；一个是“领料口”，后厨从这里领取食材。没有这两个口，服务员只能闯进后厨大声喊，供应链只能直接往锅里倒货，后厨会乱成一团。端口就是软件后厨的门洞。

在技术层面，端口是接口或抽象类。它不写实现，只写“能力”和“输入输出”。点单口就是“入端口”，也叫驱动端口，把外部用户的诉求翻译成核心能执行的用例；领料口就是“出端口”，也叫被驱动端口，把核心想调用的数据、消息、文件等能力定义成服务需求。

定义端口时，核心决定的是“菜谱需要什么”，而不是“供应商怎么送货”。例如订单服务会定义一个 OrderRepository 接口，方法可能叫“保存订单”，但不会写“连接 MySQL 的哪个表”。这样，数据库替换时，核心的“菜谱”完全不用动。

点单口和领料口一旦定下来，服务员和供应商就能各自准备。核心只认菜单和领料单，不关心写菜单的人是手写还是 iPad 点餐。这就是端口带来的“契约感”。

3. 适配器：门外世界的翻译官

点单口写的是“宫保鸡丁”，但门口的服务员可能需要把英文菜单、扫码枪、顾客语音全部翻译成这几个字。领料口写的是“冷藏鸡肉两公斤”，进来的可能是冷库、冰柜或农场直送。适配器就是这些负责翻译和搬运的角色。

驱动端适配器在外部系统这一侧，它把 HTTP 请求、CLI 命令、消息队列事件等翻译成入端口的方法调用；被驱动端适配器在资源这一侧，它把核心定义好的出端口实现成 MySQL、Redis、第三方 API 的具体操作。两者都实现了端口，却不包含业务规则。

适配器还可以充当“替身”。测试时，用一个内存版 Adapter 替代真实数据库，核心代码完全不知道也不在意。这就像后厨测试新菜时，先用一张打印好的菜单而不必真的让服务员跑一趟，只要能验证出餐流程即可。

在餐厅里，服务员和采购员可以随时换人，只要他们看得懂点单口和领料口的规定。技术框架迭代时，你只需要换掉一个适配器，而不是掀翻整个后厨。

4. 依赖方向：让箭头指向核心

传统架构经常出现“核心依赖数据库”的情况：代码里直接 new 一个数据库连接，业务方法里写 SQL。这就像菜谱上写着“必须使用某品牌冰箱的冷藏格”，一旦换冰箱，菜谱也要改。六边形架构要做的是把依赖翻过来：核心只依赖端口，数据库适配器反过来依赖端口。

这里的关键点是“源码依赖方向”和“调用执行方向”是相反的。数据库适配器确实会被核心调用，但从源码依赖看，适配器必须实现端口接口，所以它了解核心定义的端口；而核心完全不 import 任何数据库驱动。箭头指向哪一方，哪一方就拥有稳定性。

这种反转也叫依赖倒置。借助依赖注入，在程序启动的组合根处把具体适配器交给核心，核心甚至不知道当前用的是 MySQL 还是 PostgreSQL。替换数据库时，你只需要重新组装一次，核心用例一次都不改。

如果有一天你发现某个核心类里 import 了具体的数据库驱动或消息中间件 SDK，就说明有人把供应商直接塞进了后厨。停下来，把它挪到适配器里去。

5. 同类架构：洋葱、整洁与六边形是一家人

后厨会演化出不同布置：有的餐厅给后厨画成同心圆，有的画成一层层套间，但核心思想都是“重要的东西放在最里面”。六边形架构、洋葱架构、整洁架构说的其实是同一件事，只是画法和强调重点不同。

洋葱架构由 Jeffrey Palermo 提出，把核心领域放最内层，外层包裹应用层和基础设施层；整洁架构由 Robert C. Martin 提出，明确用 Use Case 和 Entity 把依赖规则分层。六边形架构则更强调端口和适配器的对称性，不规定一定要有多少个圈、多少层。

它们的共同铁律是：依赖只能由外向内，内层不依赖外层。区别主要在于术语和图形：六边形把多个端口放在六条边上，洋葱用一圈一圈的同心圆强调层次，整洁架构把接口适配器放在最外层。选择哪一种并不重要，重要的是依赖方向别画反。

无论是六边形还是洋葱，判断架构好不好，只需问一句：如果把 MySQL 换成 PostgreSQL，核心代码会变红吗？如果变红，说明依赖方向出了问题。

6. 工程实践：Go 与 Java 的落地方法

讲完思想，后厨要真正开张了。Go 和 Java 的落地风格略有不同，但都是围绕“接口做端口、结构体/类做适配器”展开。

在 Go 中，接口是隐式满足的。你可以在核心包定义 OrderStore 端口，而数据库适配器包只需要提供带有相同方法签名的结构体，不需要显式声明 implements。这让适配器可以保持轻量，也让核心包不被基础库污染。Java 则更强调显式接口和包结构：把端口 interface 放在领域层或应用层，把数据库实现放在独立的 infra 模块，通过依赖注入框架在启动时组装。

测试时也可以利用端口造“木偶”：用内存 Map 实现仓库端口，用日志打印实现通知端口。这样单元测试不需要连数据库、不需要发邮件，几十毫秒就能跑完。在 DDD 项目中，这种端口与适配器的划分往往直接对应领域服务与基础设施的边界。

给餐厅装上这两扇门之后，换供应商就像换一家农场送货：菜谱还是那张菜谱，厨房还是那个厨房，唯一的改动是采购员手里的送货单模板。这就是端口与适配器最朴素的价值。

AI 应用场景

Python 演示

from abc import ABC, abstractmethod # 端口: 仓库接口, 对应六边形的出端口class OrderRepository(ABC):    @abstractmethod    def save_order(self, order_id: int, amount: float) -> None:        pass # 端口: 通知接口, 另一个出端口class Notifier(ABC):    @abstractmethod    def send(self, message: str) -> None:        pass # 核心业务逻辑: 只依赖端口, 不知道数据库和邮件细节class OrderService:    def __init__(self, repo: OrderRepository, notifier: Notifier):        self.repo = repo        self.notifier = notifier     def place_order(self, order_id: int, amount: float) -> str:        self.repo.save_order(order_id, amount)        self.notifier.send("order placed")        return "ok" # 适配器: 用内存字典实现仓库端口class MemoryOrderRepository(OrderRepository):    def __init__(self):        self.store = {}     def save_order(self, order_id: int, amount: float) -> None:        self.store[order_id] = amount # 适配器: 用控制台打印实现通知端口class ConsoleNotifier(Notifier):    def send(self, message: str) -> None:        print("[notify]", message) # 组合根: 在程序入口把适配器注入核心if __name__ == "__main__":    repo = MemoryOrderRepository()    notifier = ConsoleNotifier()    service = OrderService(repo, notifier)    print(service.place_order(42, 199.0))

1. class OrderRepository(ABC):定义出端口，核心不关心数据存到哪。
2. class Notifier(ABC):定义另一个出端口，核心只负责发出通知意图。
3. class OrderService:核心业务逻辑，只持有端口类型的依赖。
4. def __init__(self, repo: OrderRepository, notifier: Notifier):通过构造函数注入端口，外部适配器在启动时被组装进来。
5. def place_order(self, order_id: int, amount: float) -> str:用例方法，只调用端口，不出现任何具体库名。
6. class MemoryOrderRepository(OrderRepository):内存适配器，测试时可以直接替换数据库实现。
7. service = OrderService(repo, notifier)组合根，把适配器注入核心，这是依赖反转发生的时刻。

常见误区

面试题