# Architecture Design

> System architecture design. 当用户需要设计系统架构、画架构图、讨论微服务拆分、CQRS、事件驱动、DDD等架构模式时使用此skill。

- Skill: `fengqiliu/architecture-design` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add fengqiliu/architecture-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fengqiliu/architecture-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: fengqiliu (https://skillmd.com/u/fengqiliu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fengqiliu/architecture-design

---


# System Architecture Design

系统架构设计技能，提供经过验证的架构模式和设计方法。

## 核心架构模式

### 1. 分层架构 (Layered Architecture)

```
┌─────────────────────────────────────┐
│         Presentation Layer          │
├─────────────────────────────────────┤
│         Application Layer           │
├─────────────────────────────────────┤
│           Domain Layer              │
├─────────────────────────────────────┤
│        Infrastructure Layer          │
└─────────────────────────────────────┘
```

**适用场景**：传统 Web 应用、CRUD 系统
**优点**：清晰简单，易于理解和维护
**缺点**：领域逻辑可能渗透到其他层

### 2. 微服务架构 (Microservices)

```
┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐
│Service│  │Service│  │Service│  │Service│
│  A   │  │  B   │  │  C   │  │  D   │
└──┬───┘  └──┬───┘  └──┬───┘  └──┬───┘
   │         │         │         │
   └─────────┴────┬────┴─────────┘
                  │
           ┌──────┴──────┐
           │   API Gateway │
           └──────────────┘
```

**适用场景**：大规模系统、需要独立部署、多团队协作
**优点**：独立部署、技术异构、故障隔离
**缺点**：复杂度高、数据一致性挑战

### 3. CQRS (Command Query Responsibility Segregation)

```
┌─────────────┐    Command    ┌─────────────┐
│   Command   │───────────────▶│   Command   │
│   Side      │               │   Handler   │
└─────────────┘               └──────┬──────┘
                                     │
                              ┌──────▼──────┐
                              │   Write     │
                              │   Database  │
                              └──────┬──────┘
                                     │ Sync
                        ┌────────────┴────────────┐
                        │                         │
                 ┌──────▼──────┐           ┌──────▼──────┐
                 │   Read      │           │   Read      │
                 │   Model     │           │   Model     │
                 └─────────────┘           └─────────────┘
```

**适用场景**：读写负载差异大、复杂业务逻辑
**优点**：优化读写性能、灵活的数据展示
**缺点**：最终一致性、复杂度增加

### 4. 事件驱动架构 (Event-Driven)

```
┌──────────┐    Event    ┌──────────┐    Event    ┌──────────┐
│ Producer │─────────────▶│  Event   │─────────────▶│ Consumer │
│   A      │             │   Bus    │             │   B      │
└──────────┘             └──────────┘             └──────────┘
```

**适用场景**：异步处理、实时响应、松耦合系统
**优点**：高扩展性、容错性、审计日志
**缺点**：调试困难、事务处理复杂

### 5. DDD (Domain-Driven Design)

```
┌─────────────────────────────────────────────┐
│              Bounded Context A               │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
│  │ Entity  │  │ Value   │  │ Domain  │    │
│  │         │  │ Object  │  │ Service │    │
│  └─────────┘  └─────────┘  └─────────┘    │
│  ┌─────────┐  ┌─────────┐                 │
│  │Aggregate│  │ Repository│              │
│  │  Root   │  │ Interface │              │
│  └─────────┘  └─────────┘                 │
└─────────────────────────────────────────────┘
```

**适用场景**：复杂业务逻辑、遗留系统现代化
**优点**：业务对齐、技术与业务匹配
**缺点**：学习曲线陡峭、设计成本高

## 架构设计流程

### Step 1: 需求分析

```
□ 识别核心业务能力
□ 确定系统边界（Bounded Context）
□ 识别关键质量属性（性能、安全、可扩展性）
□ 定义 SLA 目标
```

### Step 2: 模式选择

| 需求特征 | 推荐架构 |
|---------|---------|
| 小型系统、快速交付 | 分层架构 |
| 大规模、多团队 | 微服务架构 |
| 读写分离、高并发读 | CQRS |
| 异步处理、实时响应 | 事件驱动 |
| 复杂业务逻辑 | DDD |
| 高可用、低延迟 | 六边形架构 |

### Step 3: 架构设计

```
□ 绘制系统架构图
□ 定义服务/模块职责
□ 识别数据存储需求
□ 设计 API 接口
□ 定义集成和通信模式
```

### Step 4: 评审检查

```
□ 可扩展性：是否能应对未来增长？
□ 可用性：SLA 如何保障？
□ 安全性：数据如何保护？
□ 可维护性：团队能否有效维护？
□ 成本：基础设施和运营成本？
```

## 架构决策记录 (ADR)

```markdown
# ADR-001: 选择微服务架构

## Status: Accepted

## Context
- 系统需要支持 10 万并发用户
- 多团队并行开发
- 需要独立部署新功能

## Decision
采用微服务架构，将系统拆分为：
- 用户服务 (User Service)
- 订单服务 (Order Service)
- 支付服务 (Payment Service)
- 通知服务 (Notification Service)

## Consequences
### 正面
- 独立部署，部署风险降低
- 技术异构，不同服务可用不同技术栈

### 负面
- 分布式系统复杂性
- 数据一致性挑战
- 运维成本增加
```

## 输出模板

设计完成后，输出：

```
# [系统名称] 架构设计

## 1. 架构概述
[一句话描述系统架构和核心设计决策]

## 2. 架构图
[ASCII 或描述性架构图]

## 3. 核心组件
| 组件 | 职责 | 技术选型 |
|------|------|---------|
|      |      |         |

## 4. 数据存储
| 数据类型 | 存储方案 | 理由 |
|---------|---------|------|
|         |         |      |

## 5. API 设计
[主要接口列表]

## 6. 部署架构
[部署拓扑]

## 7. 关键决策
[ADR 列表]
```