# ADR-0001: Monorepo 架构

| 状态 | 接受 |
|-----|------|
| 创建日期 | 2026-05-25 |
| 作者 | 技术团队 |

## 上下文

我们需要一个能够支持多个相关应用和共享代码的代码库结构。项目包含：
- 前端 Web 应用
- 管理后台
- 后端 API 服务
- 共享的类型定义、工具函数和组件

我们需要在这些应用之间共享代码，同时保持开发体验和构建效率。

## 决策

我们决定采用 Monorepo 架构，使用以下工具：
- **Turborepo**: 作为构建系统，提供智能缓存和并行构建
- **pnpm**: 作为包管理器，提供高效的依赖管理和工作区支持
- **npm workspaces**: 配合 pnpm 实现工作区功能

## 备选方案

### 方案 1: 独立仓库 (Polyrepo)

**优点**:
- 完全的隔离
- 可以独立部署
- 适合完全独立的团队

**缺点**:
- 代码共享困难
- 依赖版本管理复杂
- 跨仓库重构困难
- 开发体验割裂

### 方案 2: Lerna

**优点**:
- 成熟的 Monorepo 工具
- 良好的发布功能

**缺点**:
- 相比 Turborepo 性能较差
- 配置较复杂
- 缓存机制不如 Turborepo 智能

## 后果

### 正面影响

1. **代码共享**: 易于在应用和服务之间共享类型、组件和工具
2. **统一管理**: 单一的依赖版本管理
3. **高效构建**: Turborepo 的增量构建和缓存
4. **团队协作**: 统一的代码库，便于代码审查和协作
5. **开发体验**: 单次启动所有服务的开发模式

### 负面影响

1. **学习曲线**: 团队需要学习 Monorepo 工具和工作流
2. **仓库大小**: 仓库会变得更大
3. **CI 复杂性**: CI 配置需要考虑 Monorepo 的特性
4. **权限管理**: 需要更细粒度的权限控制

## 相关链接

- [Turborepo 文档](https://turbo.build)
- [pnpm 工作区](https://pnpm.io/workspaces)