作为一名前端工程师，你是否也曾有过这样的崩溃时刻？深夜两点，为了修改一个kan似简单的购物车逻辑，你不得不在 componentsstore 和 api 文件夹之间反复横跳，Zui后发现改了一处Bug，却冒出了三个新坑。那种无力感，简直就像是在试图解开一团被猫咪玩乱的毛线球。

我们习惯了按照“技术类型”来划分文件夹，把所有Vue组件放一起，所有API请求放一起。这种Zuo法kan似整洁，实则暗藏杀机。今天我想和大家聊聊 Robert C. Martin提出的整洁架构，探讨它为何Neng成为拯救我们代码质量的救命稻草，以及它到底是如何设计的。

一、 现状：kan似有序的“大杂烩”

让我们先来kankan大多数项目的标准开局。打开 src 目录，结构通常是这样的：

src/
├── components/    ← UI 组件放这里
├── api/           ← 接口调用放这里
├── store/         ← 状态管理放这里
├── utils/         ← 工具函数放这里
└── views/         ← 页面视图放这里

乍一kan，井井有条，对吧？但当你真正开始写业务逻辑时噩梦往往就开始了。在这种结构下依赖关系通常是随意交叉的。组件Ke以引用Store，Store里又Neng直接调用API，API里可Neng又掺杂了业务规则。

举个具体的例子，假设我们要实现一个购物车功Neng。为了赶进度，我们可Neng会直接在 store 里写下这样的代码：

// store/cart.ts
import axios from 'axios'
export const useCartStore = defineStore => {
  const items = ref
  async function addItem {
    // 核心的业务判断逻辑被随意地丢在了状态管理库中
    if  {
      throw new Error
    }
    // 这里直接硬编码了对第三方库的依赖
    const res = await axios.post
    // 直接操作从后端拿到的原始JSON数据
    items.value.push
  }
  return { items, addItem }
})

这还没完，到了视图层，我们往往又忍不住把一部分逻辑塞进组件里：

问题出在哪里？ 这种写法就像把厨房、餐厅和垃圾房混在一起。业务规则一会儿在Store里一会儿在组件里甚至和具体的HTTP请求库死死绑在一起。哪天老板说：“咱们把axios换成fetch吧”，或者“咱们要重构到React去”，你kan着这堆代码，估计只Neng默默流泪了。因为业务逻辑和框架细节耦合得太紧，牵一发而动全身。

二、 破局：整洁架构的核心哲学

面对这种混乱，Uncle Bob 给出的解药是：业务逻辑必须独立于框架、UI、数据库等任何外部细节，依赖关系只Neng由外层指向内层。

这听起来有点抽象，其实它的核心思想非常简单粗暴：把Zui重要的东西放在Zui中心保护起来把Zui容易变的东西放在Zui外层。外层Ke以依赖内层，但内层绝不Neng感知外层的存在。

Ru果我们用这种思想来组织代码，目录结构可Neng会变成这样：

src/
├── domain/           ← 纯粹的业务逻辑
├── application/      ← 用例的编排与调度
├── infrastructure/   ← 具体的技术实现细节
└── ui/               ← 界面的渲染与交互

这里的依赖方向变得极其单一：只从外向内。就像剥洋葱一样，越往里越核心，越稳定。

为了geng直观地理解，我们Ke以kankan那个经典的同心圆结构图：

┌─────────────────────────────────┐
│   Frameworks & Drivers          │  ← Web、数据库、UI
│   ┌─────────────────────────┐   │
│   │  Interface Adapters     │   │  ← 控制器、网关、Presenter
│   │  ┌───────────────────┐  │   │
│   │  │  Application      │  │   │  ← 用例
│   │  │  Business Rules   │  │   │
│   │  │  ┌─────────────┐ │  │   │
│   │  │  │ Enterprise  │ │  │   │  ← 实体
│   │  │  │ Business    │ │  │   │
│   │  │  │ Rules       │ │  │   │
│   │  │  └─────────────┘ │  │   │
│   │  └───────────────────┘  │   │
│   └─────────────────────────┘   │
└─────────────────────────────────┘

三、 深度剖析：四层架构的职责划分

整洁架构将系统划分为四个同心圆，每一层dou有其独特的使命。让我们逐层拆解，kankan它们到底在干什么。

1. 实体层：企业的灵魂

这是Zui内层的一圈，也是整个系统的心脏。这里封装的是企业级的业务规则，或者说是通用的业务逻辑。

实体层是纯粹的POJO，它不依赖任何框架，不知道Vue是什么也不知道数据库长什么样。无论你是用React、Vue，还是用Angular、Node.js，甚至是在控制台跑脚本，实体层的代码dou应该Ke以直接复用，不需要Zuo任何修改。它是系统中Zui稳定、Zui不容易变化的部分。

2. 用例层：应用的编排者

再往外一层，是应用特定的业务规则。Ru果说实体层是“名词”，那么用例层就是“动词”。

它负责编排实体来完成具体的业务目标。比如“添加商品到购物车”就是一个用例。它不关心数据怎么存，也不关心界面怎么展示，它只关心：拿到数据 -> 调用实体规则 -> 保存结果。这一层包含了大部分的胶水代码，连接着外层的输入和内层的实体。

3. 接口适配层：数据的翻译官

这一层的主要任务是转换。它将Zui方便内部使用的数据格式，转换成Zui方便外部使用的数据格式。

比如Controller 负责处理HTTP请求，将JSON数据转换为用例层需要的参数；Presenter 负责将用例层返回的数据格式化为ViewModel供View展示；Gateway 负责将数据库的原始行数据转换为实体对象。这一层是隔离变化的关键，只要外部接口变了只改这一层就够了。

4. 框架与驱动层：Zui外层的壳

Zui外圈就是各种具体的工具和框架了。Web框架、数据库驱动、UI框架等等。这一层通常包含大量的胶水代码，用来让系统运转起来。

在整洁架构中，这一层是被“嫌弃”的，因为它Zui不稳定。Web框架可Neng会过时数据库可Neng会geng换。但好消息是因为依赖方向是指向内的，所以你换掉这个框架，核心业务逻辑毫发无损。

四、 实战：重构购物车代码

光说不练假把式。让我们用整洁架构的思想，把刚才那个乱糟糟的购物车代码重构一遍。你会发现，世界瞬间清静了。

第一步：定义实体

我们把核心的业务规则提取出来放在 domain 层。注意，这里没有任何外部依赖，纯纯的TypeScript代码。

// domain/aggregates/Cart.ts — 纯 TS，零依赖
export class Cart {
  private items: CartItem = 
  // 所有的业务规则dou在这里比如限制数量
  addItem: void {
    if  {
      throw new Error
    }
    this.items.push
  }
  canAddMore: boolean {
    return this.items.length <10
  }
}

第二步：实现用例

在 application 层，我们编写用例来编排业务逻辑。这里我们定义了一个Repository接口，但并不关心它怎么实现。

// application/usecases/AddToCartUseCase.ts — 编排逻辑
export class AddToCartUseCase {
  // 通过依赖注入获取仓储接口，而不是具体的axios
  constructor {}
  async execute {
    const cart = await this.repo.getCart
    const item = await this.repo.getItemById // 假设还有个获取商品详情的方法
    // 调用领域对象的方法，执行业务规则
    cart.addItem
    // 持久化，依然不关心具体怎么存
    await this.repo.save
  }
}

第三步：适配基础设施

在 infrastructure 层，我们才真正引入axios等外部库，去实现刚才定义的接口。这就是“适配”。

// infrastructure/repositories/ApiCartRepository.ts — 适配器
import axios from 'axios'
export class ApiCartRepository implements CartRepository {
  async getCart {
    // 这里处理 axios 请求，将 JSON 转换为领域对象
    const res = await axios.get
    return new Cart
  }
  async save {
    // 将领域对象转换为 axios 需要的 DTO
    await axios.post)
  }
  // ... 其他接口实现
}

第四步：UI层只管渲染

Zui后在 ui 层，Vue组件变得非常轻薄。它只负责响应用户点击，调用用例，然后展示结果。

kankan，现在的代码是不是清爽多了？业务规则只在 Cart.ts 里，哪怕明天要把Vue换成Svelte，把axios换成fetch，核心的购物车逻辑连一行代码dou不用动。

五、 收获：为什么要这么折腾？

你可Neng会问：“为了加个购物车，搞出这么多文件和类，是不是有点过度设计了？”

对于简单的Hello World项目，确实如此。但对于任何需要长期维护、业务逻辑复杂的项目，整洁架构带来的收益是巨大的：

可测试性极大提升因为业务逻辑不依赖外部，你Ke以不启动浏览器、不连接数据库，直接对 Cart 类进行单元测试。测试速度飞快，覆盖率极高。

技术栈可替换数据库从MySQL切到PostgreSQL？前端框架从Vue2升到Vue3？甚至从Web端搬到小程序？你只需要修改外层的适配器，核心业务逻辑完全不用动。

维护成本降低修改外层的UI或数据库逻辑，不会意外破坏内层的业务规则。依赖关系的单向性，保证了系统的稳定性。

归根结底，普通架构是按技术类型分层，而整洁架构是按依赖方向分层。

整洁架构并不是为了炫技，而是为了在软件开发的漫长生命周期中，让我们的代码始终处于可控状态。它强迫我们思考：什么是业务的核心？什么是Ke以随时抛弃的细节？

当你下次再准备在 store 里写一段 if/else 的业务判断时请停下来想一想：这段逻辑真的应该属于这里吗？把它剥离出来放到属于它的领域层去吧。相信我，未来的你，会感谢现在Zuo出了这个决定的自己。

一句话让业务逻辑成为不可撼动的核心，让数据库、框架等成为随时可插拔的细节。这就是整洁架构设计的初衷。

---