解决方案架构师技巧 - 5 种架构图类型

2025-05-24

解决方案架构师技巧 - 5 种架构图类型

您是否曾经参加过会议,有人试图解释软件系统如何运作?

我当时正和一位刚入职不久的解决方案架构师交谈,他正在尝试描述他们提出的一个系统。这个系统大约有八个不同的组件,它们之间以多种方式相互作用。

他们使用手势和大量“这个部分通过...与这个部分进行交流”来解释解决方案。

我听懂了他们嘴里说的话,但是这些话串在一起却毫无意义。

解释复杂的概念架构时,文字总是会迷失。我试图在思路的指引下构建一个心智模型。我需要一个视觉化的表达。

我需要一张图表。

但并非任何图表都适用。架构图并非“一刀切”的解决方案。

我们最近讨论过,作为解决方案架构师的一个重要部分是有效地向技术和非技术受众传达你的想法。

你的图表必须考虑到这一点。如果你想让你的想法传达给不同的人,你必须制作多个版本的图表。

今天我们将讨论根据5 个不同的受众应该制作的5 种不同类型的图表。

我们将从我的虚假业务但真实的 API Gopher Holes Unlimited中举一个例子,我们将一个新的 gopher 添加到系统中进行跟踪。

流程图

最通用、最广泛的图表是流程图。它是一种中高级图表,可以展示工作流程的所有部分。

该图说明了业务流程中的活动部分。

基本架构流程图

观众

这种图表的受众通常是技术人员。它可以用来向架构委员会提出一个想法,或者向开发人员描述一个业务流程是如何运作的。

注意事项

架构流程图的主要组成部分是包含所有活动部件。在我们的无服务器 AWS 环境,我们标记了每个托管服务以及哪些服务相互通信。

它没有详细描述各个部分如何相互作用,但确实展示了它们之间的联系,并展示了数据如何在系统中流动。

服务图

服务图从高层次展示了连接性。它不展示工作流或服务如何运作的任何细节,而是展示主要组成部分。此图旨在展示应用程序中使用的内部服务和外部服务。

架构服务图

观众

IT 和网络工程师通常对这类图表最感兴趣。他们关心您与外部服务建立的任何连接,此外,他们还需要知道是否需要监控任何内部连接。

我经常用这张图向高管们描述系统是如何工作的。他们想知道主要应用程序之间的连接,没有什么比服务图更能体现这些连接了。

注意事项

构建架构服务图时,最好列出构成应用程序或生态系统的所有微服务。标记哪些服务相互通信,并确保区分公司自有服务和外部服务。

这张高层次的图表不需要详细阐述服务的工作原理。它只介绍使应用程序运行的服务。

人物角色图

展示你的架构能够解决业务问题至关重要。角色图描述了特定工作流中按时间顺序排列的视图和参与者。这是证明你在开发解决方案时已将业务考虑在内的最佳工具。

带泳道的架构人物角色图

观众

这类图表的目标受众是业务导向的个人和产品负责人。他们关注的是用户画像以及他们如何与系统交互。向他们展示谁在何时做了什么,这能完美地描述你的系统正在做什么。

注意事项

架构角色图略微借鉴了BPMN 模型。利用泳道来展示工作流中的不同参与者。这种类型的图通常级别较低,因为它比其他类型的图包含更多细节。务必标记角色、工作流以及任何关于业务流程如何从一个步骤过渡到另一个步骤的假设。

这些图表还可以帮助刚接触某个领域的开发人员,并为他们将要构建的内容提供深刻的背景信息。

基础设施图

基础架构图是一种“所见即所得”的模型。它代表了所有已实现的功能。它本质上是一种低级图表,旨在涵盖服务/应用/生态系统中存在的所有内容。

此图旨在展示已构建的内容以及系统当前的工作方式。您可以将其视为您所构建应用程序的蓝图。

基础设施图

观众

基础架构图的受众各不相同。它可以用来向开发人员展示他们在特定微服务中需要使用的内容。它还可以用来向客户展示贵公司完成某项任务所需的所有资源。

您的基础架构图的主要受众是技术人员。由于您提供的是清单,而不是传达想法或业务流程,因此此图的预期用途仅限于提供信息。它适合那些喜欢“细节”的人。

注意事项

构建架构基础架构图时,切勿遗漏任何部分。此类图表的目标是展示应用中的所有内容及其连接方式。您无需过多地阐述其工作原理,只需专注于将应用的所有部分都包含在图中即可。

开发人员图表

当你需要深入细节时,开发人员图表将是你的最佳选择。它涵盖了开发人员构建解决方案所需的一切。其目标是通过查看流程图来解答可能出现的任何问题,并将其纳入设计中。这是所有图表中级别最低的,旨在让你无需在场的情况下就能理解设计思路。

有人应该能够读懂这张图表并确切知道该做什么。

包含详细信息的开发人员图表

观众

实现解决方案的开发人员是这里的受众。图表中包含的细节对于团队以外的人员来说是不必要的。有时,过多的细节对于不需要它的受众来说可能是件坏事。

向开发团队以外的人提供实施细节就是过度细节的典型例子。这会分散注意力,并影响你试图传达的其他信息。

注意事项

架构开发图本质上是流程图的补充细节。请用您能想到的任何具体实现细节标记每个部分,并确保标注重要的转换。

这种图表并不能取代用户故事,但它确实有助于增强用户故事,并增进整个开发团队的理解。尽可能使用它们,因为当实现完成后,您将来会拥有一个有用的参考资料。

结论

架构图有很多种类型。每种类型都有其独特的用途,并且许多类型服务于不同的受众。作为一名解决方案架构师,在向合适的人展示你的想法时,你必须能够提供合适的架构图类型。

通常情况下,一个版本的图表是不够的。当我开始一个新的设计时,我总是从流程图开始。我会把所有的想法都记录下来,然后把它提交给其他系统管理员。一旦我们就解决方案达成一致,我就会把流程图转换成角色图,然后交给业务人员。

当我得到业务部门的批准后,我就可以开始绘制开发人员图表服务图表了。服务图表会交给高管,以确保他们能够从总体上了解我们正在做的事情。开发人员图表会交给即将实施解决方案的工程师。

一旦解决方案构建完成,我们就可以更新基础设施图以包含新的工作。

一图胜千言,而架构图则可能胜过五千言。能够让人们快速轻松地理解你的想法,是成为一名优秀解决方案架构师的关键。

通过为不同受众构建不同类型的图表的能力,您可以为成功做好准备。

附言:我一直用draw.io来制作图表。它是一款免费工具,提供制作精美、全面的图表、模型和示意图所需的一切。

文章来源:https://dev.to/aws-builders/solutions-architect-tips-the-5-types-of-architecture-diagrams-3pl3
PREV
我是如何通过大部分免费内容的解决方案架构师专业考试的🥇
NEXT
我如何使用 AWS Serverless 创建一个门铃 简介 架构 工作原理 输出代码 一些经验教训 可能的改进