重要性
写好技术设计方案，可以提升开发、沟通效率，有利于明确需求、规划架构、识别风险、梳理思路。全盘思考后再去写代码，避免边写代码边思考。
参考目录结构
修订版本
修订版本按时间倒序，用于描述重大修改内容。
参考：
| 时间 | 版本号 | 修改内容 | 修改人 |
|---|---|---|---|
| 2024-11-12 | V1.1 | 补充内容 ...... | 千千菌 |
| 2024-10-10 | V1.0 | 初版 | 千千菌 |
1. 设计概要
1.1 背景
业务需求可以直接粘贴PRD上的需求，如果是内生的技术需求，考虑说清楚以下几个问题：
- 需求产生的原因(来源)是什么？
- 需要主要解决什么问题或场景？有哪些收益？
- 需求的变更范围是什么？
1.2 设计范围
功能特性：建议以列表的形式真实，包含功能编号、功能分类、功能描述等信息。
参考：
| 编号 | 功能模块 | 一级功能 | 二级功能 | ... |
|---|---|---|---|---|
非功能特性：性能、响应时间、吞吐、安全、隐私、易用性、可测试性
1.3 设计难点
1.4 术语定义
尽量和PRD中的术语保持一致
2. 架构设计/解决方案设计
2.1 整体解决方案
架构 = 模块结构 + 运行机制
- 明确目标（一个系统？服务？接口？）
- 针对目标进行结构拆解（系统 -> 服务、服务 -> 接口、接口 -> 实现类）
- 将拆解后的接口进行关联描述（连线？分层？聚合?）
2.2 架构和关系图
对于架构图的补充和细化，对不同的场景，可以选择不同类型的 UML 图来说明：模块关系图、时序图、ER图、领域模型、系统层次图、部署结构图
