系统设计（二）如何写技术设计文档

目录

为什么要写技术文档?

技术设计文档

一、业务分析

1.1 业务背景

1.2 业务用例

1.3 业务流程

 二、系统分析 

2.1 系统架构

2.2 领域模型

2.3 系统用例

2.4 数据模型

2.5 状态机

2.6 数据流转

三、 系统流程分析

3.1 外卖订购时序

3.1.1 时序图

 3.1.2 幂等设计

3.1.3 并发设计

3.1.4 兼容性设计

3.1.5 风险点设计

3.2 xx流程

四、非功能性设计

4.1 可测性设计

4.2 性能分析

4.3 并发能力设计

4.4 容错能力

4.5 运维能力

五、数据分析

六、接口设计

6.1 查询接口

七、里程碑

---

为什么要写技术文档?

作为一名优秀的架构师，系统技术方案设计文档应该是必备技能。为什么要写设计文档呢，我觉得有以下几个好处：

• 全局设计抽象：文档可以让我们更好的整理思路，避免未经详细思考，直接编码，因为直接编码可能只看到了系统的一部分，会有很多的疏漏。文档是具有目录结构，比代码的抽象层次更高，可以让我们思考全局设计，思考整体的扩展性和复用性，以及后续系统整体的解决方案，设计的更合理。站在高处看，提供一张“全景图”，会有不一样的思考。
• 更好细节设计：相信各位技术同学，都遇到过直接上手编码，经常会出现考虑不周的情况，在详细的细节实现层面由于之前考虑不周，不得不返工，在文档编写的过程中，会考虑到整个系统流程，把细节思考到位；
• 沟通和交流：我们交付的是能够让被人理解以及后续可维护的功能，一般在写文档的过程中，会和团队成员一起交流，听听别人的意见和建议，进行思想的碰撞，更容易避免“踩坑”，进行更合理的设计。
• 沉淀技术资产：经常我们在接手新的系统或者功能的时候，会面临系统资料缺失，不能很好的上手，通过编写技术设计文档，也是一种技术传承，后续在进行功能修改的时候，我们要及时更新文档，让文档保鲜，这是作为技术人的一种责任；

技术设计文档

技术文档应该是更上层的抽象，那一份优秀的技术设计文档应该有哪些部分呢，个人感觉方案设计就是业务分析+系统分析，下面我就以用“户权限控制”这个小功能，来看下如何写一份技术文档

一、业务分析

1.1 业务背景

在做设计之前，首先需要知道业务背景是什么？需要把业务PRD深入理解，我觉得可以套用5W2H法则来看，下面是摘自与百度百科的介绍

（1）WHAT——是什么？目的是什么？做什么工作？

（2）WHY——为什么要做？可不可以不做？有没有替代方案？

（3）WHO——谁？由谁来做？

（4）WHEN——何时？什么时间做？什么时机最适宜？

（5）WHERE——何处？在哪里做？

（6）HOW ——怎么做？如何提高效率？如何实施？方法是什么？

（7）HOW MUCH——多少？做到什么程度？数量如何？质量水平如何？费用产出如何？

这里找了一篇比较完整的prd文档：PRD的标准写法一套全面文档规范（完整版带模板） | PM28

为什么要做这个需求？需求是核心解决了什么问题？期望什么时间上线？达成什么样的目标？

1.2 业务用例

一般会先分析当前功能会有几个使用角色，根据不同的角色分析对应的业务用例，也就是用户的操作功能。