架构描述到底是什么?

发表于 2022-02-06 更新于 2022-02-07 分类于架构师之路阅读次数：本文字数： 1.9k 阅读时长 ≈ 2 分钟

作为一名程序员，你历经千幸万苦终于成为了架构师。

现在你接到了一个任务，需要设计一款软件。

你满心欢雀，冥思苦想。

系统在你心里一点一点成型，数据库如何设计？代码如何实现？组件如何部署？你脑海里都有了答案。

是时候了，你倾尽全力设计的系统，应该让所有人都来欣赏！

可是，该如何表达你的设计，你的思想呢？

程序员的时候，你只需要跟相关开发同学打交道，完成组长分配给你的开发任务，那时候你的思想都在代码里，一个个设计模式，一行行代码，甚至几行零散的注释，都是你思想设计的结晶。现在你是架构师了，你需要跟业务、开发、测试、运维打交道，他们中很多一部分人根本就看不懂你的代码，况且项目刚开始还没有代码。

所以我们要找一个合适，一个让相关方都看得懂的东西来呈现、来描述我这完美的架构，这就是架构描述，而最终通过某一个模板呈现出来的产物就是 架构文档。

编写一份合格的架构设计文档是架构师的必备技能，那现在，让我们开始吧。

首先，让我们回过头来明确一下架构描述的作用。

所有利益相关方都有权利理解架构，架构模型建立了设计词汇，统一了建模语言，架构描述则将这些模型转化为利益相关方可以理解的形式。架构描述最重要的作用之一就是向业务相关方展示软件架构是如何实现需求目标和提升质量属性的。
优秀的架构描述能促进沟通与协作，将设计决策和思想有效的传递给每个人，提高软件开发质量。
如果不试着编写架构描述，很容易就会以为所有东西你都清楚了，只有当你笔尖触到纸的那一刻，你才明白，你脑子里的想法只不过是一团浆糊。编写架构描述可以帮我们理清思路，强迫我们搞清楚什么是我们知道的，什么是我们认为我们知道的，还有什么时候我们不知道的。
架构描述提供了一种可以分析设计决策的媒介，让我们可以及时发现错误。花一个下午解释一个愚蠢的想法，总比花费一个月的开发时间要好的多。
架构描述是展示系统的有效方式，客户和领导看到你的设计的时候他们就会明白，你已经完全理解了他们的业务需求，设计出来的产品正是他们所需要的，增强他们的信心与支持。

架构描述非常重要，对于软件的成功起着至关重要的作用，不过那完全是基于架构描述能够有效、准确的描述利益相关方诉求这一前提条件，什么样的架构描述才是有效描述？有效描述有什么特征？

整体来说，有效描述有以下几个关键特征：

（1）根据受众的需求进行定制

重点考虑利益相关方关心的问题；使用受众熟悉的领域语言（统一建模语言），提高可理解性；尽量使用大白话，避免使用生僻的行话；使用标准模板，更显专业。

（2）用多个视图展示架构

不同的人有不同的关注点，架构描述尽量做到以人为本，不同的相关方展示不同的视点及视图。

（3）清晰定义元素及其功能

给架构描述中出现的元素和符号赋予特定意义

（4）解释设计决策的逻辑依据

我们在架构描述中列出淘汰方案相当于对决策过程进行回放，能够让他人理解我们是怎么走到这里的，当他们越了解你的决策依据就越容易接受你的设计意图。

提架构描述，有几个重要概念是无论如何需要掌握的，那就是架构视点、视图、图表。

架构的视图是一组相关关注点的视角看整个系统的一种表示法。

架构的视点是用于构建和利用一个视图的常规说明书。它是一个模式或模板，可以利用它确定一个视图的目标和用户及其创建和分析的技术，从而开发单独的视图。

概念比较拗口，咱们可以这样理解：视点可以理解成架构文档中的目录，视图的模板，定义视图的技术。

如上，业务相关方关注的是我们是否理解并能实现他们的业务需求，所以我们在架构描述中需要展示需求视点；而开发小伙伴关注的是系统需要实现哪些功能，所以我们提供功能视点……

很多人觉得视图就是一张图表，但实际上他们的关系是包含的关系。即：一个视图可能通过一个简单的图表就能完整的描绘，但更常见的场景是一个视图需要许多图表进行描绘。

编写架构描述很少是从头开始，大部分情况下架构师会找一个专业的架构设计模板，而后从一个视点目录选择视点并在必要的情况下调整它们以达到他或她的需要。不管怎样，创建架构模板，模板应该包含几个部分：

此部分主要包含架构标题、版本说明、目录等

架构中的所有决策都基于利益相关方的诉求，因此在描述设计之前有必要列出这些诉求。

软件架构非常庞杂，很难用一张图表完整展示。为了方便利益相关方理解，按照不同的视点组织相关视图来解释软件如何满足质量属性和其他需求。

总结已知的风险和未解决的问题。这样做的目的是在已知的“雷区”周围点亮红灯，提醒以后的设计人员。