如何编写一份合格的架构设计文档

在软件开发中，作为一名工程师，经常会遇到需要技术设计文档的场景。比如项目验收时，需要技术设计文档作为验收材料；进行岗位晋升时，需要技术设计文档作为晋升材料；解决遗留系统问题时，如果有设计文档会使问题得到更快速的解决 ......

总之，作为一位软件工程师，会编写一份合格的架构设计文档是必备技能。今天，根据最近的学习，对如何编写架构设计文档做一个简单的总结。

主要从三个方面进行介绍：

• 谁需要编写架构设计文档

• 为什么需要架构设计文档

• 架构设计文档应该包含哪些内容

谁需要编写架构设计文档

很明显，是架构师需要编写架构设计文档。但是什么是架构师？

架构师是做架构设计、对系统架构负责的那个人。

架构师是是一顶帽子，而不是一把椅子；架构师是一个角色而不是一个职位。

架构师不是一个职位，不是一个 title , 而是做架构设计这件事的人。任何一个简单的系统都需要做架构设计，只是架构设计的复杂度不同。只要你在负责对一个系统进行架构设计，你就是这个系统的架构师。

架构师的主要职责

架构师的主要能力

为什么需要架构设计文档

架构设计文档是对一个系统的软件架构的具象化描述，是架构师系统设计思维的具体展示。

什么是软件架构

维基百科中对软件架构的描述如下：

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

软件架构的组成，如下图：

软件架构组成

从上图可以看出，架构文档是针对不同相关方，对系统软件架构的一种描述，用于阐述系统的架构设计，有利于指导后期系统的研发和运维等工作，是架构师进行软件架构设计过程中的输出产物。

架构设计文档应该包含哪些内容

架构设计文档是由 架构视图 组成。

4+1 视图模型

软件架构 = { 元素 ，形式 ，关系/ 约束 }

根据不同相关方的关注点不同，架构由多个视图组成，单一视图无法完整表达架构。

4+1 视图模型是由 IBM 提出，具体描述可以参见参考资料链接 2 。

该模型主要包含 5 个视图，具体如下：

• 逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。

• 过程视图（Process View），捕捉设计的并发和同步特征。

• 物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。

• 开发视图（Development View），描述了在开发环境中软件的静态组织结构。

• 场景视图（scenarios）,描述用例场景。

逻辑视图

• 相关方：客户、用户、开发组织管理者

• 视角：系统的功能元素，以及它们的接口，职责，交互

• 主要元素：系统，子系统，功能模块，子功能模块，接口

• 用途：开发组织划分，成本、进度评估

开发视图

• 相关方：开发相关人员，测试人员

• 视角：系统如何开发实现

• 主要元素：描述系统的层，分区，包，框架，系统通用服务，业务通用服务，类和接口，系统平台和相关基础框架

• 用途：指导开发组织设计和开发实现

物理视图

• 相关者：系统集成商，系统运维人员

• 视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置

• 主要元素：物理节点以及节点的通信

过程视图

• 相关者：性能优化，开发相关人员

• 视角：系统运行时线程，进程的情况

• 主要元素：系统进程，线程以及处理队列等

场景视图

• 相关者：用户，设计和开发人员

• 视角：概括了架构上最重要的场景（最典型或者最有危险）及其非功能性需求，通过这个场景的实现，阐明了架构的广度或众多架构元素运行的方式

总结

以上，就是针对架构设计文档主要由哪些架构视图组成做了简单介绍，文章中主要介绍了概念，对于具体如何建立模型，绘制视图未做具体介绍，后期会对如何使用 UML 进行软件架构设计进行学习总结。希望对大家有所帮助。