从分层架构到整洁架构-软件架构设计思想的演进与抉择

从分层架构到整洁架构：软件架构设计思想的演进与抉择

导语：架构设计不是堆砌模式，而是在约束条件下做最优决策。本文从传统分层架构的困局出发，逐层拆解六边形架构、洋葱架构、整洁架构的核心设计思想，结合实际项目中架构选型的真实决策过程，帮助你建立起一套可复用的架构设计思维框架。

一、传统分层架构的黄金时代与隐忧

1.1 分层架构为什么统治了二十年

分层架构（Layered Architecture）的核心思想极为朴素：将系统按职责垂直切分，上层依赖下层，下层不感知上层。典型的四层模型——表现层（Presentation）、业务层（Business）、持久层（Persistence）、数据库层（Database）——几乎出现在每一个早期的企业级项目中。

它的成功源于三个关键优势：

但问题恰恰出在"理解成本低"上。当业务复杂度突破某个阈值后，分层架构的"简单"变成了"简陋"。

1.2 分层架构的四个致命伤

致命伤一：业务逻辑泄漏到基础设施层

在一个典型的分层项目中，Service层充斥着SQL拼接、缓存操作、消息队列调用：

// 典型的分层架构 Service 代码
public class OrderService {
public void createOrder(OrderDTO dto) {
// 业务逻辑与基础设施代码混杂
String sql = "SELECT stock FROM inventory WHERE product_id = ?";
int stock = jdbcTemplate.queryForObject(sql, Integer.class, dto.getProductId());
if (stock < dto.getQuantity()) {
throw new BusinessException("库存不足");
}
// 更多SQL、Redis、MQ操作…
}
}

致命伤二：依赖方向失控

理论上依赖应该是单向的：Controller → Service → Repository。但实际项目中，Service之间循环依赖、Service直接操作Redis/ES、甚至跨层反向依赖，比比皆是。

致命伤三：测试成本指数级增长

因为业务逻辑和基础设施代码耦合在一起，单元测试必须mock掉数据库、Redis、MQ等所有外部依赖。一个简单的下单逻辑，测试代码可能是业务代码的3-5倍。

致命伤四：技术栈迁移成为灾难

当需要从MySQL迁移到PostgreSQL，或从Redis迁移到本地缓存时，改动会像病毒一样扩散到所有Service层代码。

二、六边形架构：把"外部世界"关进笼子

2.1 核心思想：端口与适配器

Alistair Cockburn在2005年提出的六边形架构（Hexagonal Architecture），也被称为端口与适配器架构（Ports & Adapters），其核心思想可以用一句话概括：

业务逻辑是系统的核心，数据库、UI、消息队列、外部API都是"外部世界"，通过端口（接口）与核心交互。

六边形架构的拓扑结构如下：

┌──────────────────────┐
│ Primary Adapters │
│ (REST, CLI, WebUI) │
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ Primary Ports │
│ (Application API) │
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ Application Core │
│ (Business Logic) │
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ Secondary Ports │
│ (Repository, MQ) │
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ Secondary Adapters │
│ (MySQL, Redis, Kafka) │
└──────────────────────┘

2.2 端口与适配器的落地实践

在Java项目中落地六边形架构，关键做法是：

步骤一：定义端口（接口）

// 端口定义在核心层，不依赖任何外部框架
public interface OrderRepository {
Optional<Order> findById(OrderId id);
void save(Order order);
}

步骤二：实现适配器

// 适配器实现放在基础设施层，可以随时替换
@Repository
public class MySqlOrderRepository implements OrderRepository {
private final JdbcTemplate jdbc;

@Override
public Optional<Order> findById(OrderId id) {
// 具体实现…
}
}

步骤三：依赖注入方向由外向内

所有的依赖箭头都指向核心领域层。外部适配器依赖端口接口，端口接口定义在核心层。

2.3 六边形架构的实战收益

某互联网金融项目在从传统分层架构迁移到六边形架构后，取得了显著效果：

• 单元测试覆盖率从32%提升到78%，单测编写时间减少60%
• 数据库迁移（Oracle→MySQL）的代码改动范围从200+文件缩减到仅12个适配器文件
• 新成员理解核心业务逻辑的时间从2周缩短到3天

三、洋葱架构：层次化的依赖规则

3.1 Jeffrey Palermo的洞见

2008年，Jeffrey Palermo在六边形架构的基础上提出了洋葱架构（Onion Architecture）。他的核心贡献是：将依赖规则按层次严格定义，越往内层越抽象、越稳定，越往外层越具体、越易变。

洋葱架构的四层结构：

┌──────────────────────────────┐
│ Infrastructure │
│ (DB, MQ, External API) │
│ ┌──────────────────────┐ │
│ │ Application Services│ │
│ │ (Use Cases, DTOs) │ │
│ │ ┌──────────────┐ │ │
│ │ │ Domain Model │ │ │
│ │ │ (Entities, │ │ │
│ │ │ Value Objs, │ │ │
│ │ │ Aggregates) │ │ │
│ │ └──────────────┘ │ │
│ └──────────────────────┘ │
└──────────────────────────────┘

3.2 洋葱架构的关键约束

约束一：依赖方向只能由外向内

外层可以依赖内层，内层绝不能依赖外层。Domain层不应该import任何框架相关的类。

约束二：接口定义在内层，实现在外层

这与六边形架构的端口适配器思想一脉相承。接口属于领域层或应用层，具体实现属于基础设施层。

约束三：内层对象不能持有外层对象的引用

Domain层的实体不能持有JPA的EntityManager，Application层的Service不能直接操作HttpServletRequest。

3.3 洋葱架构与六边形架构的区别

四、整洁架构：Robert C. Martin的集大成

4.1 整洁架构的四层模型

Robert C. Martin在2012年提出的整洁架构（Clean Architecture），本质上是对六边形架构和洋葱架构的整合与升华。它的核心规则只有一条：

源代码依赖方向必须指向核心业务逻辑。内层的任何变化都不应该影响外层。

整洁架构的四层模型：

4.2 依赖反转原则（DIP）的实战运用

整洁架构的精髓在于依赖反转：

// Use Case 层定义了接口（内层）
public interface UserRepository {
User findById(UserId id);
}

// Use Case 层的业务逻辑（内层）
public class CreateOrderUseCase {
private final UserRepository userRepository; // 依赖接口，不依赖实现

public Order execute(CreateOrderRequest request) {
User user = userRepository.findById(request.getUserId());
// 纯业务逻辑…
}
}

// Framework 层实现接口（外层）
@Repository
public class JpaUserRepository implements UserRepository {
// JPA 具体实现…
}

4.3 整洁架构的边界划分实践

整洁架构强调"按组件边界打包"，而非"按技术分层打包"。一个典型的包结构：

com.example.order/
├── domain/ # 实体层
│ ├── Order.java
│ ├── OrderItem.java
│ └── OrderStatus.java
├── usecase/ # 用例层
│ ├── CreateOrderUseCase.java
│ ├── OrderRepository.java (接口)
│ └── CreateOrderRequest.java
├── adapter/ # 适配层
│ ├── web/
│ │ └── OrderController.java
│ └── persistence/
│ └── JpaOrderRepository.java
└── infra/ # 基础设施
└── config/

五、架构选型的决策框架

5.1 四种架构模式的适用场景对比

5.2 从分层架构到整洁架构的迁移策略

策略一：绞杀者模式（Strangler Fig）

不推倒重来，而是在现有分层架构上逐步包裹整洁架构的外壳。新功能按整洁架构编写，老功能逐步重构。

策略二：领域先行

先识别核心领域模型，将Domain层从Service层中剥离。Domain层不依赖任何框架，纯POJO + 领域行为。

策略三：端口提取

将Service层中对外部系统的调用（数据库、缓存、消息队列）逐步提取为端口接口，然后用适配器模式实现。

5.3 决策检查清单

在做架构选型时，建议依次检查以下问题：

六、全文总结

架构设计思想从分层架构、六边形架构、洋葱架构到整洁架构的演进，本质上是一个**“将业务逻辑从基础设施中解放出来”**的过程。每一种架构模式都不是银弹，而是特定约束条件下的最优解。

关键认知：

• 分层架构是入门，简单但容易腐化
• 六边形架构通过端口与适配器隔离了内外部
• 洋葱架构通过严格的层次依赖管理保护了领域核心
• 整洁架构通过依赖反转和边界划分实现了可持续的架构演进

选择哪种架构，取决于你的项目复杂度、团队能力和业务生命周期。

七、架构行业发展展望

随着云原生、微服务、Serverless的普及，架构设计思想正在经历新一轮的演进：

参考文献