清洁架构：分层设计与依赖反转原则

概述

清洁架构是一种以业务逻辑为核心、强调解耦与可维护性的软件架构模式。其核心目标是让业务规则独立于技术实现（如UI、数据库、第三方库），并通过依赖反转原则（外层依赖内层）确保系统的可测试性、可扩展性与长期维护性。

核心概念

四层架构模型

清洁架构通过分层结构实现技术细节与业务逻辑的隔离，具体分为以下四层：

1. Entities（实体层）

   • 定义领域模型和业务规则，是纯粹的业务逻辑核心。
   • 示例：用户身份验证规则、订单状态转换逻辑。

2. Use Cases（用例层）

   • 实现具体的业务流程，调用实体层完成任务。
   • 示例：用户注册流程、支付订单的校验与执行。

3. Interface Adapters（接口适配层）

   • 负责数据格式转换，如HTTP请求解析、数据库查询结果映射。
   • 示例：将REST API请求转换为实体层可识别的数据结构。

4. Frameworks & Drivers（框架驱动层）

   • 包含技术实现细节，如Web框架（Express、Spring）、数据库（PostgreSQL）、UI组件等。
   • 示例：MySQL连接池、gRPC服务端实现。

工作原理

依赖反转原则

• 外层依赖内层：框架驱动层（如Web框架）可以依赖接口适配层，但内层（如实体层）不能直接依赖外层。
• 通过接口通信：内层通过定义接口（如数据库操作接口）与外层交互，避免硬编码技术实现。

依赖方向示例

[Frameworks & Drivers]  
    ↓（依赖）  
[Interface Adapters]  
    ↓（依赖）  
[Use Cases]  
    ↓（依赖）  
[Entities]  

使用方法

典型项目结构

application/
├── cmd/              # 启动命令（如main.go）
├── internal/
│   ├── domain/       # Entities：领域模型与接口
│   ├── usecase/      # Use Cases：业务逻辑实现
│   ├── adapter/      # Interface Adapters：HTTP控制器、数据库适配器
│   └── layer/        # Infrastructure：数据库实现、第三方依赖
├── pkg/              # 工具函数/共用库

目录命名建议

常见问题与注意事项

1. 依赖方向错误

• 错误示例：实体层直接调用数据库驱动（如Entities中使用mysql.DB）。
• 正确做法：通过接口定义数据库操作（如DBRepository接口），由接口适配层实现具体技术细节。

2. 技术实现污染业务逻辑

• 风险：在实体层中引入第三方库（如time、json）可能导致业务规则与技术细节耦合。
• 解决方案：将技术细节封装在框架驱动层，通过接口传递数据。

3. 目录结构混乱

• 建议：遵循internal/domain、internal/usecase等命名规范，避免将技术实现（如数据库代码）混入业务逻辑目录。

总结

清洁架构通过分层与依赖反转原则，实现了业务逻辑与技术细节的解耦。其核心价值在于：

• 可测试性：业务逻辑独立于框架，便于单元测试。
• 可维护性：技术实现变更不影响核心业务规则。
• 可扩展性：新增功能可通过扩展外层实现，无需修改内层代码。

实际应用中需严格遵循依赖方向，避免技术细节渗透到业务层，同时通过统一的目录结构提升代码可读性。