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

顾星 · 2 小时前

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

问题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, 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 两个目录中来回横跳，非常的麻烦，接口越多你越接近地狱。
质疑三：整洁架构的单一方向

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

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

复制代码

# 整洁架构的结构
# 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的推理方式：

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

复制代码

关键区别：

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

Python 的特殊情况

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

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

复制代码

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

复制代码

结论

大小界定是伪命题：用"项目大小"来选择架构没有客观标准，用 port 数量来衡量复杂度反而更具体
六边形的双向依赖是设计缺陷：入站/出站两个方向增加了认知负担，尤其在动态语言中
整洁架构是进化，不是替代：它统一了依赖方向，消除了六边形的复杂性，独绝了循环依赖的发生
对比本身就是错误的：就像比较 iPhone 4 和 iPhone 15，它们不是"选择关系"，而是"进化关系"
对 AI 编程极其友好：单一依赖方向意味着 AI 可以更准确地推理代码结构

附录：依赖方向的可视化

下面这个图是用AI画的

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

复制代码

单一方向的价值：

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

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

账号		自动登录	找回密码
密码			立即注册

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

相关帖子

签约作者

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

相关帖子

相关推荐

签约作者