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

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

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

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

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

---

一个"公认"的观点

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

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

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

质疑一：大小如何界定？

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

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

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

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

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

# 六边形架构的依赖方向
# 入站方向
入站Adapter → 入站Port → Domain# 出站方向  
Domain ← 出站Port ← 出站Adapter

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

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

# ports/inbound/order_service.py
from abc import ABC, abstractmethodclass OrderServicePort(ABC): # 这就相当于 OrderService 的接口定义@abstractmethoddef create_order(self, order_dto: OrderDTO) -> Order:pass# ports/outbound/payment_gateway.py
class PaymentGatewayPort(ABC):@abstractmethoddef charge(self, amount: Decimal) -> PaymentResult:pass# 问题来了：当你看到 Domain 层调用 payment_gateway 时
# 你需要去哪里找 Adapter？
# adapters/outbound/stripe/？adapters/outbound/paypal/？
# 还是 adapters/inbound/ 里有个奇怪的实现？

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

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

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

Frameworks → Interface Adapters → Use Cases → Entities←———————————— 所有依赖指向内层 ————————————←

# 整洁架构的结构
# entities/order.py
@dataclass
class Order:id: OrderIditems: list[OrderItem]status: OrderStatusdef 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_repoself.payment_gateway = payment_gatewaydef 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的推理方式：

Prompt: "在整洁架构中，我需要添加一个新的支付方式 PayPal"AI 的推理路径：
1. PaymentGateway 接口在 usecases 层定义 ✓
2. 新的 PayPalGateway 在 adapters 层实现 ✓
3. 依赖方向：adapters → usecases ✓
4. 不需要修改任何内层代码 ✓

对比六边形架构：

Prompt: "在六边形架构中，我需要添加一个新的支付方式 PayPal"AI 的推理路径：
1. 这是入站 Port 还是出站 Port？需要判断...
2. 如果是出站 Port，Adapter 放在哪个目录？
3. 需要检查现有的 Port 定义位置...
4. 命名约定是什么？PaymentGatewayPort？PayPalAdapter？

---

反驳与修正

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

反驳一：CRUD 场景呢？

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

这个批评是伪需求。

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

# 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侵入代码这种写法都干得出来，充其量是代码太屎，而是不架构有问题。

反驳二：穿层问题

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

穿层不是诱惑，是违规。

# 错误示例：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"一样，所以说，问"用六边形还是整洁架构"也是伪命题。

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

# 六边形架构的目录结构
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（抽象基类）：

# 六边形架构中，你需要区分这是入站 Port 还是出站 Port
class OrderServicePort(ABC):  # 入站@abstractmethoddef create_order(self, dto: OrderDTO) -> Order: ...class PaymentGatewayPort(ABC):  # 出站@abstractmethoddef charge(self, amount: Decimal) -> PaymentResult: ...# 从代码本身，你无法区分哪个是入站、哪个是出站
# 只能靠目录结构推断

# 整洁架构中，所有 Port 都在 usecases 层
# 它们的角色是统一的：被外层实现
class OrderRepository(ABC):@abstractmethoddef save(self, order: Order) -> None: ...class PaymentGateway(ABC):@abstractmethoddef charge(self, amount: Decimal) -> PaymentResult: ...# 不需要区分方向，只需要知道：外层实现，内层调用

---

结论

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

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

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

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

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

---

附录：依赖方向的可视化

下面这个图是用AI画的

六边形架构：┌─────────────────┐│   Inbound       ││   Adapter       │└────────┬────────┘│▼
┌──────────────┐      ┌─────────────┐      ┌──────────────┐
│  Outbound    │◄─────│   Domain    │─────►│  Inbound     │
│  Adapter     │      │             │      │  Port        │
└──────────────┘      └─────────────┘      └──────────────┘▲                    ││                    │└────────────┬───────┘│┌──────▼──────┐│  Outbound   ││  Port       │└─────────────┘依赖方向：双向（入站向内，出站向外）整洁架构：┌────────────────────────────────────────────────────────┐
│                    Frameworks                          │
│  ┌──────────────────────────────────────────────────┐  │
│  │              Interface Adapters                  │  │
│  │  ┌────────────────────────────────────────────┐  │  │
│  │  │              Use Cases                     │  │  │
│  │  │  ┌──────────────────────────────────────┐  │  │  │
│  │  │  │            Entities                  │  │  │  │
│  │  │  └──────────────────────────────────────┘  │  │  │
│  │  └────────────────────────────────────────────┘  │  │
│  └──────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────┘依赖方向：单向（永远指向内层）

单一方向的价值：

• 代码审查时检查点明确
• IDE 依赖分析工具容易验证
• 新人理解成本低
• AI 辅助编程推理路径清晰
• 不会出现循环依赖
• 模块天然内聚，特别容易从文件名的语义上就发现是否会出现类的“泄漏”或“跳层”