# 设计架构

## 规则（Rules）

# 系统架构设计规范

## 1. 分层设计

系统必须按分层架构划分：前端层、API网关层、业务服务层、数据访问层、基础设施层。

✅ 每层职责清晰，层间通过接口通信
❌ 所有逻辑混在一起，没有分层

## 2. 技术选型有依据

每个技术选型必须列出选型理由和备选方案。

✅ "选用Vue.js：团队熟悉、生态丰富、性能满足需求；备选：React"
❌ "就用Vue.js"（没有理由）

## 3. 非功能需求

架构设计必须体现性能、安全和可扩展性要求。

✅ "系统需支持1000QPS，99.9%可用性"
❌ 只考虑功能不考虑性能

## 4. 文档命名

核心架构文档必须固定使用 `架构设计文档(ADD).md`。

✅ `./project/{项目名}/doc/架构设计文档(ADD).md`
❌ `projectx_architecture_design_v1.0.md`

## 方法（Methods）

# 系统架构设计方法

## 步骤

### 1. 分析需求
分析需求文档，提取功能需求和非功能需求（QPS、可用性、安全性）。

### 2. 设计模块划分
将系统划分为5层：前端层、API网关层、业务服务层、数据访问层、基础设施层。创建架构设计文档。

### 3. 技术选型
对每个模块选择技术栈，列出选型理由和备选方案。

### 4. 设计接口规范
定义模块间通信方式（RESTful API / gRPC / 消息队列）。

### 5. 输出文档
确保文档包含：架构概述、模块划分、技术选型、接口规范、部署架构、安全设计、性能预估。

## 技巧（Tips）

# 系统架构设计技巧

## 1. KISS原则

只在必要时引入复杂度，能用简单方案就不用复杂方案。

| 方案 | 复杂度 | 适用场景 |
|------|--------|---------|
| 单体应用 | 低 | 团队<10人，业务简单 |
| 微服务 | 高 | 团队>50人，业务复杂 |
| 事件驱动 | 中 | 需要异步处理，高并发 |

## 2. 常见问题

| 问题 | 原因 | 解决 |
|------|------|------|
| 架构过于复杂 | 过度设计 | 简化设计，非核心功能拆分到后续迭代 |
| 技术选型有风险 | 选用了不成熟的技术 | 准备备选方案，标注风险等级 |
| 模块边界不清 | 职责划分不明确 | 重新划分模块职责和边界 |