共计 2618 个字符，预计需要花费 7 分钟才能阅读完成。
申明：
本文转自 DEV Community 网站，文章翻译由开发者社区提供；
点击下方链接，查看英文原文：
- https://dev.to/aws-builders/s…
在您加入过的会议中，是否曾有人解释软件系统是如何运行的？
我已经和一个入行不久的解决方案架构师交换过，他试图向我形容他们设计进去的零碎：包含大概八个不同的组件，彼此之间以不同的形式互相通信。
在形容这个解决方案的过程中，他们不停地应用手势，以及大量的“这个部件通过 …… 与那个部件进行通信”句式。
他们说的每一个单词我都晓得，但连起来之后我就搞不懂了。
在解释简单的概念架构时，语言就会失去意义。我正在遵循着一个思路搭建一个心理模型。我须要一个视觉展示模式。
我须要一个图表
但不是一般的图表。架构图并不是一个万能的解决方案。
咱们最近探讨过，作为一名解决方案架构师，重要的一点是无效地将你的想法传播给技术和非技术受众。
你的图表必须思考到这一点。如果你想把想法传递给不同的人，你必须制作不同版本的图表。
咱们在这里要探讨的是，应该依据 5 种不同的受众，制作 5 种不同类型的图表。
咱们将以实在的 API，Gopher Holes Unlimited 为例，在零碎中增加一个新的查问 gopher。
流程图
流程图是最通用、影响最宽泛的图表。它是一个中高级的图表，蕴含工作流程的所有局部。
这张图展现了一个业务流程中的流动局部。
受众
流程图的受众个别是技术型的。它能够用来向架构委员会论述构想，也能够向开发人员形容某个业务流程是如何运行的。
注意事项
架构流程图次要由各个流动局部组成。在咱们的无服务器 AWS 环境中，咱们给每个托管的服务，以及哪些服务之间能够互相通信贴上标签。
咱们没有详细描述各局部之间如何相互作用，但展现了连贯状况，即显示出数据如何在零碎中流动。
服务图
服务图从较高层级上展现了连接性。它不蕴含工作流或服务如何运行等细节，而是展现发挥作用的要害局部。下图展现了应用程序中应用的外部和内部服务。
受众
IT 和网络工程师往往对这种类型的图表最感兴趣。他们关怀如何与内部服务进行连贯，另外，他们还想晓得是否须要对任何外部连贯进行监控。
我常常应用服务图向高管论述零碎的工作原理。他们想晓得次要应用程序之间是如何连贯的，没有什么比服务图更适宜出现这些连贯了。
注意事项
搭建一个架构服务图时，最好列出所有组成应用程序或生态系统的微服务。表明哪些服务之间是互相通信的，并确保对外部服务和内部服务做出辨别。
在这类高层级图表中，无需具体阐明各个服务是如何运作的。所有使利用程序运行的服务都是如此。
角色图
表明您的架构可能解决业务问题，这一点十分重要。角色图展现了一个按工夫顺序排列的视图，以及特定工作流中的不同角色。它是证实您在制订解决方案时将业务考量在内的最佳工具。
受众
该类图表的指标受众包含以业务为导向的集体和产品所有者。他们关注角色，以及如何与零碎进行交互。这样一个展现“谁，在何时，做了什么”的图表，可能向受众完满地形容您的零碎。
注意事项
角色图有点相似于 BPMN 模型，利用泳道来展现工作流中的不同角色。这类图表往往是低层级的，因为它蕴含更多的细节。要表明角色、工作流以及业务流程如何从一个步骤转到另一个步骤。
角色图也能够帮忙刚涉足某个畛域的开发者，为他们行将开发的货色提供丰盛的背景信息。
基础设施图
基础设施图是一个“所见即所得”的模型。它代表所有曾经实现的货色。它在实质上是一个低层级的图表，包含服务 / 利用 / 生态系统中存在的所有。
基础设施图旨在展现曾经建设的货色和零碎以后的工作形式。能够把看做您构建的应用程序的蓝图。
受众
基础设施图具备不同的受众。它能够用于向开发者展现在特定的微服务中须要解决的问题。也能够用于向客户展现您公司用于实现一项工作的全副资源。
技术人员是基础设施图的次要使用者。因为您提供的是一个清单，而不是展现想法或业务流程，所以此类图的预期应用范畴只限于信息。它是为那些喜爱“细枝末节”的人筹备的。
注意事项
制作架构基础设施图时，不要脱漏任何局部。此类图表的指标是展现应用程序中的所有内容，以及它们是如何连贯的。您无需深刻理解所有的细节，而是要确保将应用程序中的所有局部都蕴含在图中。
开发者图
在须要深刻理解状况时，开发者图是最佳抉择。它蕴含了开发者在构建解决方案时须要的所有。指标是解答任何在查看流程图时可能呈现的问题，并将其纳入设计中。这是最低层级的图表，旨在在您不在场的状况下传播您的想法。
应该有人可能读懂这张图，并分明地晓得该怎么做。
受众
此类图的受众是施行解决方案的开发者。对于团队以外的人员来说，图表蕴含的细节水平是不必要的。有时候，对于不须要太多细节的受众来说，过多的细节可能是一件好事。
向开发团队以外的人员提供施行细节很好地阐明了细节太多并不是一件坏事。它会导致注意力的扩散，并覆盖您想要传播的其余信息。
注意事项
开发者图实质上是增加了细节的流程图。标记出您能想到的任何一个具体的施行细节，还要标记出重要的过渡。
此类图表并不能取代用户故事，但它的确有助于强化用户故事，进步整个开发团队的了解程度。在能够应用开发者图的时候应用，因为在施行完结当前，您就领有了一个能够在将来参考的工具。
总结
架构图有很多类型。每一种都有一个非凡的目标，为不同的受众服务。作为一名解决方案架构师，您必须可能在提出想法的同时，向正确的受众提供正确类型的图表。
在很多状况下，一个版本的图表是不够的。当我开始进行新的设计时，我总是从流程图动手。我会把我所有的想法写下来，而后获取其余解决方案架构师的认同。一旦咱们就解决方案达成统一，我就会把它变成角色图，而后拿给业务人员看。
当我取得业务部门的批准后，我就能够制作开发者图和服务图。服务图是针对高管的，以便确保他们对咱们正在做的事件有一个较高层次的理解。开发者图是针对那些将要施行解决方案的工程师的。
一旦构建起解决方案，咱们就能够更新基础设施图，将新的工作涵盖进来。
一张图片抵过一千个词汇，但架构图可能胜过五千个。可能让人们轻松、疾速地了解您的想法，是成为一名优良的解决方案架构师的要害。
可能为不同的受众建设不同类型的图表，您就为胜利做好了筹备。
P.S. – 我习惯应用 draw.io 来构建图表。这是一个收费的工具，它提供了制作好看详尽的图表、模型和图示所须要的所有资源。
文章作者：Allen Helton
Allen Helton for AWS Community Builders
