# {模块名称} - 架构设计文档

> **module**: {模块名}
> **doc_type**: Architecture
> **status**: Draft / Review / Active
> **owner**: {负责人}
> **upstream_docs**: 01-prd.md, 02-user-journey.md
> **last_verified**: YYYY-MM-DD

---

## 架构摘要

| 字段 | 内容 |
|------|------|
| 模块定位 | {模块在系统中的定位} |
| 前端入口 | {如 `/module` 及其子路由} |
| 后端入口 | {如 `/api/v1/module/*`} |
| 主聚合根 | {核心实体，如"Order"；次级核心实体列表} |
| 关键依赖 | {依赖的外部模块/服务} |

---

## 分层边界

### 前端层
- {框架和组件组织方式}

### 应用层
- {Controller 职责边界}

### 领域层
- {Service 职责和关键业务域}

### 基础设施层
- {持久化、外部服务集成}

---

## 当前后端结构

### 控制器

| 控制器 | 说明 |
|--------|------|
| `{name}.controller.ts` | {职责} |

### 服务

| 服务 | 责任 |
|------|------|
| `{Name}Service` | {职责} |

---

## 当前前端结构

### 页面路由

| 页面 | 路由 | 说明 |
|------|------|------|
| {页面名} | `/{module}/{path}` | {说明} |

---

## 关键数据流

> 用简短的编号步骤描述核心业务流程的数据流向。详细状态转换见 04-state-machine.md，不在此重复。

1. {步骤 1}
2. {步骤 2}

---

## 架构约束

- {约束 1，如"所有写操作 API 必须返回完整资源对象"}
- {约束 2，如"不允许根据历史文档恢复已移除的前端入口"}

---

## 实施阶段

> 新功能和大改动按 Phase 顺序实施，前一阶段验证通过后再进入下一阶段；小修复（bugfix、局部补丁）可直接跳到受影响阶段，但必须验证上游依赖未被破坏。

### Phase 1: {基础层名称}

- **内容**: {本阶段实现什么，引用 PRD F编号}
- **依赖**: 无
- **影响范围**: {涉及的 controller/service 和前端页面}
- **验证**: {如何验证本阶段完成}

### Phase 2: {核心层名称}

- **内容**: {本阶段实现什么}
- **依赖**: Phase 1
- **影响范围**: {涉及的 controller/service 和前端页面}
- **验证**: {如何验证}

> Phase 数量按模块复杂度调整。关键原则：每个 Phase 可独立验证，依赖关系显式声明，影响范围明确到文件级别。