六边形架构是什么
六边形架构又称端口与适配器架构：领域核心通过端口定义自己需要的能力与对外提供的能力，适配器负责把具体技术实现接到端口上，例如 HTTP 控制器、数据库仓储、消息消费者。核心不依赖框架与基础设施，依赖方向由外向内。它的实用判据很直接：能否在不启动 Web 框架和数据库的情况下，对核心业务逻辑做单元测试。
基本信息
| 入站适配器 | 把外部请求（HTTP、命令行、消息）转换为对核心用例的调用 |
|---|---|
| 出站适配器 | 实现核心定义的接口，对接数据库、第三方 API、文件存储 |
| 端口 | 核心定义的一组接口，分为驱动端口与被驱动端口 |
| 关键规则 | 依赖方向由外向内，核心代码不引入框架与基础设施类型 |
| 收益 | 核心逻辑可独立测试、替换实现不改业务代码 |
端口与适配器示例
端口与适配器示例
# 出站端口：核心需要的能力
interface OrderRepository { save(order); findById(id) }
# 入站端口：外部可调用的用例
interface SubmitOrderUseCase { submit(cmd): Result }
# 适配器：JPA 仓储与 HTTP 控制器分别实现上述接口
# 核心只依赖接口，测试时用内存实现替换典型使用场景
- 业务规则复杂：希望脱离框架快速测试核心逻辑
- 多入口访问：同一用例同时由 HTTP 接口、命令行工具与消息触发
- 更换基础设施：数据库或消息中间件替换时只改适配器
- 遗留系统改造：为核心定义端口，逐步替换旧实现
- 测试策略：用内存实现替换外部依赖，提高测试速度与稳定性
- 第三方集成：把供应商 SDK 隔离在适配器内，避免污染领域模型
常见偏离信号
| 信号 | 问题 | 影响 |
|---|---|---|
| 领域层 import 框架注解 | 核心依赖基础设施 | 无法脱离框架测试，替换成本高 |
| 仓储接口返回框架实体 | 接口泄漏技术细节 | 上层被迫依赖 ORM 类型 |
| 控制器里写业务分支 | 用例逻辑外移 | 多入口行为不一致 |
| 端口定义过细 | 每个方法一个接口 | 接口数量膨胀，维护成本上升 |
六边形架构与整洁架构、洋葱架构表达的依赖规则一致，区别主要在术语与图形表达方式，落地时不必纠结名称。
把“六边形”理解成必须恰好六个模块是常见误解：六边形只是示意外的多个入口与出口，数量取决于实际适配器个数。