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: 模式选择

Step 3: 架构设计

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

Step 4: 评审检查

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

架构决策记录 (ADR)

# 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 列表]