name: 设计架构 description: 设计软件架构并为项目选择合适的模式。在设计系统、选择架构模式、构建项目、做出技术决策，或者当被问及微服务、单体应用或架构方法时使用。

设计架构

架构决策工作流

复制此清单并跟踪进度：

架构设计进度：
- [ ] 第一步：理解需求和限制
- [ ] 第二步：评估项目规模和团队能力
- [ ] 第三步：选择架构模式
- [ ] 第四步：定义目录结构
- [ ] 第五步：记录权衡和决策
- [ ] 第六步：根据决策框架进行验证

模式选择指南

按项目规模

规模	推荐模式
小型 (<10K LOC)	简单的 MVC/分层
中型 (10K-100K)	清洁架构
大型 (>100K)	模块化单体或微服务

按团队规模

团队	推荐
1-3 开发者	单体应用，清晰的模块
4-10 开发者	模块化单体
10+ 开发者	微服务（如果合理）

常见模式

1. 分层架构

┌─────────────────────────────┐
│       表示层          │  ← UI, API 控制器
├─────────────────────────────┤
│       应用层           │  ← 用例，服务
├─────────────────────────────┤
│         领域              │  ← 业务逻辑，实体
├─────────────────────────────┤
│      基础设施         │  ← 数据库，外部API
└─────────────────────────────┘

使用场景：简单的 CRUD 应用，小团队，快速原型

2. 清洁架构

┌─────────────────────────────────────┐
│            框架和驱动程序      │
│  ┌─────────────────────────────┐    │
│  │     接口适配器       │    │
│  │  ┌─────────────────────┐    │    │
│  │  │   应用层       │    │    │
│  │  │  ┌─────────────┐    │    │    │
│  │  │  │   领域    │    │    │    │
│  │  │  └─────────────┘    │    │    │
│  │  └─────────────────────┘    │    │
│  └─────────────────────────────┘    │
└─────────────────────────────────────┘

使用场景：复杂的业务逻辑，长期项目，测试性是关键

3. 六边形（端口和适配器）

        ┌──────────┐
        │ HTTP API │
        └────┬─────┘
             │ 端口
    ┌────────▼────────┐
    │                 │
    │   应用层   │
    │     核心        │
    │                 │
    └────────┬────────┘
             │ 端口
        ┌────▼─────┐
        │ 数据库 │
        └──────────┘

使用场景：需要交换外部依赖，多个入口点

4. 事件驱动架构

生产者 → 事件总线 → 消费者
              │
              ├─→ 消费者
              │
              └─→ 消费者

使用场景：需要松耦合，异步处理，可扩展性

5. CQRS（命令查询责任分离）

┌─────────────┐      ┌─────────────┐
│  命令   │      │   查询   │
│  (写入)    │      │   (读取)    │
└──────┬──────┘      └──────┬──────┘
       │                    │
       ▼                    ▼
  写入模型          读取模型
       │                    │
       └────────┬───────────┘
                ▼
           事件存储

使用场景：不同的读写扩展，复杂领域，事件源

目录结构模式

基于特性（推荐中型+）

src/
├── 特性/
│   ├── 用户/
│   │   ├── api/
│   │   ├── 组件/
│   │   ├── 钩子/
│   │   ├── 服务/
│   │   └── 类型/
│   └── 订单/
│       ├── api/
│       ├── 组件/
│       └── ...
├── 共享/
│   ├── 组件/
│   ├── 钩子/
│   └── 工具/
└── 应用/
    └── ...

基于层（简单应用）

src/
├── 控制器/
├── 服务/
├── 模型/
├── 仓库/
└── 工具/

决策框架

在做出架构决策时，根据这些标准进行评估：

简单性 - 从简单开始，需要时发展
团队技能 - 将架构与团队能力相匹配
需求 - 让业务需求驱动决策
可扩展性 - 考虑增长轨迹
可维护性 - 为变化优化

权衡分析模板

使用此模板记录架构决策：

## 决策：[我们正在决定的内容]

### 上下文
[为什么现在需要这个决策]

### 考虑的选项
1. 选项 A：[描述]
2. 选项 B：[描述]

### 权衡
| 标准 | 选项 A | 选项 B |
|----------|----------|----------|
| 复杂性 | 低 | 高 |
| 可扩展性 | 中等 | 高 |
| 团队熟悉度 | 高 | 低 |

### 决策
我们选择了[选项]，因为[理由]。

### 后果
- [这使得什么成为可能]
- [这限制了什么]

验证清单

在选择架构后，根据以下内容进行验证：

架构验证：
- [ ] 与项目规模和复杂性匹配
- [ ] 与团队技能和经验一致
- [ ] 支持当前需求
- [ ] 允许预期增长
- [ ] 依赖关系向内流动（核心没有外部依赖）
- [ ] 模块/层之间有清晰的界限
- [ ] 测试策略是可行的
- [ ] 权衡已记录

如果验证失败，请重新考虑模式选择或调整实施方法。