声明：
本文转自 DEV Community 网站，文章翻译由开发者社区提供；
点击下方链接，查看英文原文：
在您参加过的会议中，是否曾有人解释软件系统是如何运行的？
我曾经和一个入行不久的解决方案架构师交流过，他试图向我描述他们设计出来的系统：包括大约八个不同的组件，彼此之间以不同的方式相互通信。
在描述这个解决方案的过程中，他们不停地使用手势，以及大量的“这个部件通过......与那个部件进行通信”句式。
他们说的每一个单词我都知道，但连起来之后我就搞不懂了。
在解释复杂的概念架构时，语言就会失去意义。我正在遵循着一个思路搭建一个心理模型。我需要一个视觉展现形式。
我需要一个图表
但不是普通的图表。架构图并不是一个万能的解决方案。
我们最近探讨过，作为一名解决方案架构师，重要的一点是有效地将你的想法传达给技术和非技术受众。
你的图表必须考虑到这一点。如果你想把想法传递给不同的人，你必须制作不同版本的图表。
我们在这里要讨论的是，应该根据 5 种不同的受众，制作5种不同类型的图表。
我们将以真实的 API，Gopher Holes Unlimited为例，在系统中添加一个新的查询 gopher。
流程图
流程图是最通用、影响最广泛的图表。它是一个中高级的图表，包含工作流程的所有部分。
这张图展示了一个业务流程中的活动部分。
受众
流程图的受众一般是技术型的。它可以用来向架构委员会阐述构想，也可以向开发人员描述某个业务流程是如何运行的。
注意事项
架构流程图主要由各个活动部分组成。在我们的无服务器 AWS 环境中，我们给每个托管的服务，以及哪些服务之间可以相互通信贴上标签。
我们没有详细描述各部分之间如何相互作用，但展示了连接情况，即显示出数据如何在系统中流动。
服务图
服务图从较高层级上展示了连接性。它不包含工作流或服务如何运行等细节，而是展示发挥作用的关键部分。下图展示了应用程序中使用的内部和外部服务。
受众
IT 和网络工程师往往对这种类型的图表最感兴趣。他们关心如何与外部服务进行连接，另外，他们还想知道是否需要对任何内部连接进行监控。
我经常使用服务图向高管阐述系统的工作原理。他们想知道主要应用程序之间是如何连接的，没有什么比服务图更适合呈现这些连接了。
注意事项
搭建一个架构服务图时，最好列出所有组成应用程序或生态系统的微服务。标明哪些服务之间是相互通信的，并确保对内部服务和外部服务做出区分。
在这类高层级图表中，无需详细说明各个服务是如何运作的。所有使应用程序运行的服务都是如此。
角色图
表明您的架构能够解决业务问题，这一点非常重要。角色图展示了一个按时间顺序排列的视图，以及特定工作流中的不同角色。它是证明您在制定解决方案时将业务考量在内的最佳工具。
受众
该类图表的目标受众包括以业务为导向的个人和产品所有者。他们关注角色，以及如何与系统进行交互。这样一个展示“谁，在何时，做了什么”的图表，能够向受众完美地描述您的系统。
注意事项
角色图有点类似于 BPMN 模型，利用泳道来展示工作流中的不同角色。这类图表往往是低层级的，因为它包含更多的细节。要标明角色、工作流以及业务流程如何从一个步骤转到另一个步骤。
角色图也可以帮助刚涉足某个领域的开发者，为他们即将开发的东西提供丰富的背景信息。
基础设施图
基础设施图是一个“所见即所得”的模型。它代表所有已经实现的东西。它在本质上是一个低层级的图表，包括服务/应用/生态系统中存在的一切。
基础设施图旨在展示已经建立的东西和系统当前的工作方式。可以把看做您构建的应用程序的蓝图。
受众
基础设施图具有不同的受众。它可以用于向开发者展示在特定的微服务中需要处理的问题。也可以用于向客户展示您公司用于完成一项任务的全部资源。
技术人员是基础设施图的主要使用者。由于您提供的是一个清单，而不是展示想法或业务流程，所以此类图的预期使用范围只限于信息。它是为那些喜欢“细枝末节”的人准备的。
注意事项
制作架构基础设施图时，不要遗漏任何部分。此类图表的目标是展示应用程序中的所有内容，以及它们是如何连接的。您无需深入了解所有的细节，而是要确保将应用程序中的所有部分都包含在图中。
开发者图
在需要深入了解情况时，开发者图是最佳选择。它包含了开发者在构建解决方案时需要的一切。目标是解答任何在查看流程图时可能出现的问题，并将其纳入设计中。这是最低层级的图表，旨在在您不在场的情况下传达您的想法。
应该有人能够读懂这张图，并清楚地知道该怎么做。
受众
此类图的受众是实施解决方案的开发者。对于团队以外的人员来说，图表包含的细节程度是不必要的。有时候，对于不需要太多细节的受众来说，过多的细节可能是一件坏事。
向开发团队以外的人员提供实施细节很好地说明了细节太多并不是一件好事。它会导致注意力的分散，并掩盖您想要传达的其他信息。
注意事项
开发者图本质上是添加了细节的流程图。标记出您能想到的任何一个具体的实施细节，还要标记出重要的过渡。
此类图表并不能取代用户故事，但它确实有助于强化用户故事，提高整个开发团队的理解水平。在可以使用开发者图的时候使用，因为在实施结束以后，您就拥有了一个可以在未来参考的工具。
总结
架构图有很多类型。每一种都有一个特殊的目的，为不同的受众服务。作为一名解决方案架构师，您必须能够在提出想法的同时，向正确的受众提供正确类型的图表。
在很多情况下，一个版本的图表是不够的。当我开始进行新的设计时，我总是从流程图入手。我会把我所有的想法写下来，然后获取其他解决方案架构师的认同。一旦我们就解决方案达成一致，我就会把它变成角色图，然后拿给业务人员看。
当我获得业务部门的同意后，我就可以制作开发者图和服务图。服务图是针对高管的，以便确保他们对我们正在做的事情有一个较高层次的了解。开发者图是针对那些将要实施解决方案的工程师的。
一旦构建起解决方案，我们就可以更新基础设施图，将新的工作涵盖进来。
一张图片抵过一千个词汇，但架构图可能胜过五千个。能够让人们轻松、快速地理解您的想法，是成为一名优秀的解决方案架构师的关键。
能够为不同的受众建立不同类型的图表，您就为成功做好了准备。
P.S. - 我习惯使用 draw.io 来构建图表。这是一个免费的工具，它提供了制作美观详尽的图表、模型和图示所需要的一切资源。
文章作者： Allen Helton
Allen Helton for AWS Community Builders
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。