用六边形架构与整洁架构对比是伪命题？

ray_liang2026-03-03 15:27

最近有几个朋友不约而同地在问我这样的一些问题:

问题1： 六边形架构与整洁架构选哪个更好？ 问题2：查资料说六边形架构更适合于中小型项目，而整洁架构更适合用于大型项目是这样吗？

在论述我的观点之前，还是我一贯的风格先说答案：

用 六边形架构与整洁架构 做横向对比就好像用 iPhone17 与 iPhone4 对比一样，你会选哪个？

一个"公认"的观点

观点：很多人认为整洁架构只适合大型项目，而六边形架构更适用于中小型项目。

我也用AI查过这个问题，貌似有些模型却实是给出了这样的选型答案。

这个观点听起来很合理，我也在一些热门的架构书籍中看过这个观点，甚至被广泛接受。但它经得起推敲吗？

质疑一：大小如何界定？

"大项目"和"小项目"的划分没有客观标准。这个批评是成立的，但是却又是【无理取闹】的。

如果非要用一个指标来衡量复杂度，那么port 的数量（接口）是一个最具体也最能反映问题的。我在实践中发现一但 port 增多，六边形架构就越容易出现混乱，很容易出现【找不到Adapter】或者【找错Adapter】的情况。

为了让更多的朋友看懂，本文选用 python 为代码示例

质疑二：六边形架构的双向问题

六边形架构的 port 分为两类：

python 复制代码 
# 六边形架构的依赖方向
# 入站方向
入站Adapter → 入站Port → Domain

# 出站方向  
Domain ← 出站Port ← 出站Adapter

其实从认知上来说在 Java , C# 这些优秀的面向对象语言之中 六边形架构就是一种鸡肋，用分层架构就足够了。因为 Port 就是接口，Adapter 就是实现，那以 Java 的写法 接口有时可能从文件名看不出，但实现一定是 XXXImpl.java, 而C# 就是返过来如 IRepository -> OrderRepository 不过习惯了就好，这是惯例的知识，所以在这两种语言中去实践六边形会非常的便扭，代码反而很难看。

六边形是两个方向的分离，那就意味着认知负担翻倍。在 Python 这种没有原生接口的语言中，问题就显得更严重：

python 复制代码 
# ports/inbound/order_service.py
from abc import ABC, abstractmethod

class OrderServicePort(ABC): # 这就相当于 OrderService 的接口定义
    @abstractmethod
    def create_order(self, order_dto: OrderDTO) -> Order:
        pass


# ports/outbound/payment_gateway.py
class PaymentGatewayPort(ABC):
    @abstractmethod
    def charge(self, amount: Decimal) -> PaymentResult:
        pass


# 问题来了：当你看到 Domain 层调用 payment_gateway 时
# 你需要去哪里找 Adapter？
# adapters/outbound/stripe/？adapters/outbound/paypal/？
# 还是 adapters/inbound/ 里有个奇怪的实现？

"找不到 Adapter" 的情况在六边形架构中并不罕见，尤其是项目演进一段时间后。最蛋疼的是，你想用IDE去跳转实现代码，那你得失望了，因为这是一种抽象层级的定义与实现，IDE并【认不出来】你得手工找。当 Adapter 很多的时候每次你都得在 In / Out 两个目录中来回横跳，非常的麻烦，接口越多你越接近地狱。

质疑三：整洁架构的单一方向

整洁架构的依赖规则极其简单：

markdown 复制代码 
Frameworks → Interface Adapters → Use Cases → Entities
     ←------------------------------------ 所有依赖指向内层 ------------------------------------←
python 复制代码 
# 整洁架构的结构
# entities/order.py
@dataclass
class Order:
    id: OrderId
    items: list[OrderItem]
    status: OrderStatus
    
    def total_amount(self) -> Decimal:
        return sum(item.price for item in self.items)


# usecases/create_order.py
class CreateOrderUseCase:
    def __init__(self, order_repo: OrderRepository, payment_gateway: PaymentGateway):
        self.order_repo = order_repo
        self.payment_gateway = payment_gateway
    
    def execute(self, command: CreateOrderCommand) -> Order:
        order = Order.create(command.items)
        self.payment_gateway.charge(order.total_amount())
        self.order_repo.save(order)
        return order


# adapters/payment/stripe_gateway.py
class StripePaymentGateway(PaymentGateway):
    def charge(self, amount: Decimal) -> PaymentResult:
        # Stripe SDK 调用
        pass


# adapters/persistence/sql_order_repo.py
class SqlOrderRepository(OrderRepository):
    def save(self, order: Order) -> None:
        # SQLAlchemy 持久化
        pass

依赖方向永远指向内核。无论项目大小，这个规则不变。这就意味着整洁架构永远不会出现【循环依赖】，有且只有具备单一方向依赖的架构是不会出现【循环依赖】的。

对于 AI 辅助编程，这种确定性极其重要，你的AI是不会写错代码的或者写代码出错的机率大大降低，我们尝试推理一下AI的推理方式：

markdown 复制代码 
Prompt: "在整洁架构中，我需要添加一个新的支付方式 PayPal"

AI 的推理路径：
1. PaymentGateway 接口在 usecases 层定义 ✓
2. 新的 PayPalGateway 在 adapters 层实现 ✓
3. 依赖方向：adapters → usecases ✓
4. 不需要修改任何内层代码 ✓

对比六边形架构：

markdown 复制代码 
Prompt: "在六边形架构中，我需要添加一个新的支付方式 PayPal"

AI 的推理路径：
1. 这是入站 Port 还是出站 Port？需要判断...
2. 如果是出站 Port，Adapter 放在哪个目录？
3. 需要检查现有的 Port 定义位置...
4. 命名约定是什么？PaymentGatewayPort？PayPalAdapter？

反驳与修正

我遇到最有意思的一些常见问题

反驳一：CRUD 场景呢？

有人会说："整洁架构对 CRUD 项目来说太重了。"

这个批评是伪需求。

CRUD 场景下讨论架构是【没有意义的】。首先，CURD不是业务操作，是数据操作没有业务性。没有业务复杂度就没有架构问题，只有代码规范问题。把"整洁架构对 CRUD 冗余"当作批评点，本身就是靶子立错了。

python 复制代码 
# CRUD 场景：直接在 Controller 里操作数据库，完全没问题
@app.route("/users", methods=["POST"])
def create_user():
    user = User(name=request.json["name"])
    db.session.add(user)
    db.session.commit()
    return jsonify(user.to_dict())

这不是"糟糕的架构"，这是没有架构 。对于纯 CRUD，这就是正确的选择。即使这在这个create_user 中你直接写SQL最多只能是批评代码的人太水了，将SQL侵入代码这种写法都干得出来，充其量是代码太屎，而是不架构有问题。

反驳二：穿层问题

又有人说："整洁架构的层次多了，会有穿层的诱惑。" （另一种说法叫：【数据透传】）

穿层不是诱惑，是违规。

python 复制代码 
# 错误示例：Frameworks 层直接调用 Entities 层
@app.route("/orders", methods=["POST"])
def create_order():
    order = Order.create(request.json)  # 跳过了 Use Cases 层
    order_repo.save(order)              # 跳过了 Interface Adapters 层
    return jsonify(order.to_dict())

整洁架构的依赖规则是硬约束，违反就是错的，没有灰色地带。这和六边形架构的"双向依赖"有本质区别------前者是明确的错误，后者是设计本身的复杂性。

其实上面这个示例还漏了一点，那就是DI，如果你的整洁架构没有DI就容易出现上面的种情况，因为你得去构造，整洁架构中的构造只有在起动的装配位置出现，通过DI管理实例，用接口承接实现。这自然是不会出现所谓的 【透传】这么可笑的情况。

第三回合：核心洞察

六边形架构 vs 整洁架构：不是对比，是进化

把六边形架构和整洁架构放在一起"对比选型"，本身就是认知错误与【伪命题】。

从历史演进看：

架构 年份 核心贡献
分层架构 早期 分离关注点
六边形架构 2005 提出 Port/Adapter，解耦内外部
整洁架构 2012 统一依赖方向，消除双向复杂性

【整洁架构是六边形架构的进化版本】，它修复了六边形的双向依赖复杂性。

就像没人会问"应该用 iPhone 15 还是 iPhone 4"一样，所以说，问"用六边形还是整洁架构"也是伪命题。

代码对比：同一个业务场景

python 复制代码 
# 六边形架构的目录结构
order-service/
├── domain/
│   └── order.py
├── ports/
│   ├── inbound/
│   │   └── order_service.py      # Port
│   └── outbound/
│       └── payment_gateway.py    # Port
└── adapters/
    ├── inbound/
    │   └── rest/
    │       └── order_controller.py  # Adapter for order_service
    └── outbound/
        ├── stripe/
        │   └── stripe_payment.py    # Adapter for payment_gateway
        └── paypal/
            └── paypal_payment.py    # Adapter for payment_gateway


# 整洁架构的目录结构
order-service/
├── entities/
│   └── order.py
├── usecases/
│   ├── create_order.py
│   └── ports/                    # 接口定义在这里
│       ├── order_repository.py
│       └── payment_gateway.py
└── adapters/
    ├── controllers/
    │   └── order_controller.py
    ├── gateways/
    │   ├── stripe_gateway.py
    │   └── paypal_gateway.py
    └── persistence/
        └── sql_order_repo.py

关键区别：

  1. 六边形 ：Port 分散在 ports/inbound 和 ports/outbound，需要记住两套规则
  2. 整洁 ：所有接口都在 usecases/ports，依赖方向统一指向 entities

Python 的特殊情况

Python 没有原生接口，只能用 ABC（抽象基类）：

python 复制代码 
# 六边形架构中，你需要区分这是入站 Port 还是出站 Port
class OrderServicePort(ABC):  # 入站
    @abstractmethod
    def create_order(self, dto: OrderDTO) -> Order: ...

class PaymentGatewayPort(ABC):  # 出站
    @abstractmethod
    def charge(self, amount: Decimal) -> PaymentResult: ...

# 从代码本身，你无法区分哪个是入站、哪个是出站
# 只能靠目录结构推断
python 复制代码 
# 整洁架构中，所有 Port 都在 usecases 层
# 它们的角色是统一的：被外层实现
class OrderRepository(ABC):
    @abstractmethod
    def save(self, order: Order) -> None: ...

class PaymentGateway(ABC):
    @abstractmethod
    def charge(self, amount: Decimal) -> PaymentResult: ...

# 不需要区分方向，只需要知道：外层实现，内层调用

结论

  1. 大小界定是伪命题：用"项目大小"来选择架构没有客观标准，用 port 数量来衡量复杂度反而更具体

  2. 六边形的双向依赖是设计缺陷：入站/出站两个方向增加了认知负担，尤其在动态语言中

  3. 整洁架构是进化，不是替代：它统一了依赖方向，消除了六边形的复杂性，独绝了循环依赖的发生

  4. 对比本身就是错误的：就像比较 iPhone 4 和 iPhone 15，它们不是"选择关系"，而是"进化关系"

  5. 对 AI 编程极其友好：单一依赖方向意味着 AI 可以更准确地推理代码结构

附录：依赖方向的可视化

下面这个图是用AI画的

markdown 复制代码 
六边形架构：
                    ┌─────────────────┐
                    │   Inbound       │
                    │   Adapter       │
                    └────────┬────────┘
                             │
                             ▼
┌──────────────┐      ┌─────────────┐      ┌──────────────┐
│  Outbound    │◄─────│   Domain    │─────►│  Inbound     │
│  Adapter     │      │             │      │  Port        │
└──────────────┘      └─────────────┘      └──────────────┘
        ▲                    │
        │                    │
        └────────────┬───────┘
                     │
              ┌──────▼──────┐
              │  Outbound   │
              │  Port       │
              └─────────────┘

依赖方向：双向（入站向内，出站向外）


整洁架构：

┌────────────────────────────────────────────────────────┐
│                    Frameworks                          │
│  ┌──────────────────────────────────────────────────┐  │
│  │              Interface Adapters                  │  │
│  │  ┌────────────────────────────────────────────┐  │  │
│  │  │              Use Cases                     │  │  │
│  │  │  ┌──────────────────────────────────────┐  │  │  │
│  │  │  │            Entities                  │  │  │  │
│  │  │  └──────────────────────────────────────┘  │  │  │
│  │  └────────────────────────────────────────────┘  │  │
│  └──────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────┘

依赖方向：单向（永远指向内层）

单一方向的价值：

  • 代码审查时检查点明确
  • IDE 依赖分析工具容易验证
  • 新人理解成本低
  • AI 辅助编程推理路径清晰
  • 不会出现循环依赖
  • 模块天然内聚，特别容易从文件名的语义上就发现是否会出现类的"泄漏"或"跳层"
相关推荐
Java编程爱好者2 小时前
字节二面：被问“大模型知识过时了怎么解？”，我答“微调”，面试官当场黑脸：“听说过 RAG 吗？”
架构
Ray Liang3 小时前
用六边形架构与整洁架构对比是伪命题？
java·python·c#·架构设计
Java水解3 小时前
Java 中间件：Dubbo 服务降级（Mock 机制）
java·后端
葫芦的运维日志6 小时前
从手动部署到GitOps只需四步
架构
sumuve6 小时前
从100行到1行：我是如何重构IoT设备实时数据通信的？
架构·响应式设计
koddnty7 小时前
c++协程控制流深入剖析
后端·架构
SimonKing7 小时前
OpenCode AI辅助编程，不一样的编程思路，不写一行代码
java·后端·程序员
Mintopia7 小时前
Vite 与 Uni-App X 的协作原理：从前端开发到多端运行的桥梁
架构
FastBean7 小时前
Jackson View Extension Spring Boot Starter
java·后端
热门推荐
01GitHub 镜像站点02OpenClaw 使用和管理 MCP 完全指南03OpenClaw + 飞书（Feishu）环境搭建指南04Clawdbot部署教程：解决‘gateway token missing’授权问题的完整步骤05Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services06OpenClaw优化飞书API 额度已耗尽问题07【OpenClaw 本地实战 Ep.3】突破瓶颈：强制修改 openclaw.json 解锁 32k 上下文记忆08Window 10部署openclaw报错node.exe : npm error code 12809小黑课堂计算机二级WPSoffice题库软件下载安装教程（2026年3月最新版）10OpenClaw大龙虾机器人完整安装教程