VIBE CODING

软件系统的可视化表示

软件图表是帮助人们理解、设计、沟通和维护软件系统的可视化表示。

admin

Jul 24, 2026 • 11 min read

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

与其阅读数千行代码，一张精心选择的图表可以在几秒钟内传达大局观——或关键细节。

将它们视为以下人员之间的沟通工具：

开发者 ↔ 开发者
开发者 ↔ 架构师/技术负责人
开发者 ↔ 产品经理/利益相关者
现任 ↔ 未来的开发者（维护和入职）

1、C4 vs UML

UML（统一建模语言） 是一个正式的ISO标准，包含14种图表类型——类图、序列图、用例图、活动图、组件图、部署图等等。

C4模型 是Simon Brown创建的轻量级架构思维框架。它将架构组织为四个抽象层次：

C4不替代UML——它使用不同的视角。你可以使用UML符号、Mermaid、简单的方框和箭头或任何你喜欢的工具来绘制C4图表。模型定义的是抽象层次，而不是符号。

2、实用的图表建议

使用C4作为主要/默认语言 来处理你交给开发者的几乎所有内容：

上下文图 ——每个功能规范中必填（显示新连接器在大局中的位置），是一个高层可视化，将系统显示为单个过程，并说明它如何与外部实体交互。
容器图 ——显示内部的主要可部署/可运行单元——构成系统的应用程序、数据库、服务、API和队列。
序列图 （用Mermaid绘制，不是完整的UML）——序列图是交互图，详细说明操作如何执行。它们捕获协作上下文中对象之间的交互。序列图以时间为中心，通过使用图表的垂直轴表示时间来可视化显示交互的顺序，即发送什么消息以及何时发送。
数据流框 （规范模型→映射→客户形状）——非常C4风格，不是严格的ERD/UML。数据流图（DFD）是一种图形工具，用于表示数据如何在系统中移动

仅在真正需要时添加UML元素 （并明确指出它们）：

如果流程有10+个复杂分支/错误情况，使用详细的 UML序列图
如果你正在显著更改内部领域模型类，使用 UML类图
对于转换引擎内部的复杂编排逻辑，使用 UML活动图

一到三张清晰的图表胜过十五张技术上正确但难以阅读的图表。如果一张图表比它描述的代码更难阅读，就简化它。

3、上下文图

上下文图 （也称为0级数据流图）是一个高层可视化，将系统显示为单个过程，并说明它如何与外部实体交互。

核心思想 很简单：你将系统绘制为单个形状（通常是圆形或圆角矩形），并显示与之交互的所有外部内容。你故意忽略系统内部的内容——那是后续更详细图表的内容。

三个要素：

系统 ——在中心绘制为一个单元。在此级别，其内部是一个黑盒。
外部实体 ——向系统发送数据或从系统接收数据的人员、组织或其他系统。它们位于系统边界外部。
数据流 ——显示系统与每个外部实体之间移动的信息的箭头。每个箭头都标记了它携带的数据。

为什么使用它？

上下文图非常适合项目的开始，因为它们回答："谁与这个系统通信，他们发送/接收什么？"它们足够简单，非技术利益相关者也能理解，并且有助于确定范围——什么在内，什么在外。

关键规则： 外部实体永远不会相互链接，只能链接到系统。如果客户直接与供应商通信，那超出了你的系统范围，不会出现在这里。

4、容器图

容器图 是C4第2级。它打开上下文图的系统边界，显示内部的主要可部署/可运行单元——构成系统的应用程序、数据库、服务、API和队列。

核心组件

系统边界： 图表显示你正在建模的软件系统内部的容器。
容器： 每个主要可部署单元显示为一个方框。关键示例包括：
服务器端Web应用程序 （例如Java Spring Boot、Node.js API）
客户端Web应用程序 （例如React、Angular、Vue.js应用程序）
移动应用程序 （例如iOS或Android应用程序）
微服务
数据存储 （例如PostgreSQL数据库、MongoDB）
文件系统 （例如Amazon S3存储桶）
关系： 容器之间的箭头显示交互和依赖关系，并标记通信协议（例如"通过(JSON/HTTPS)进行API调用"、"从(JDBC)读取/写入"）。
外部人员和系统： 第1级图中的用户和外部系统也会显示，说明它们如何与系统内部的容器交互。

容器图回答的三个问题：

这个系统的可部署部分是什么？
每个部分运行在什么技术上？
它们如何通信（HTTP、SQL、异步队列等）？

以下是使用AWS Lambda、API Gateway和CloudFront作为核心容器的容器图。

每个元素代表什么：

紫色方框 ——应用程序容器（服务、前端、工作者）
蓝色方框 ——数据存储和基础设施（数据库、队列、缓存）
青色方框 ——边界外的外部参与者或系统
虚线矩形 ——系统边界（你的团队拥有的部分）
标记协议的箭头 ——容器之间的通信契约

关键规则： 箭头标记的是通信机制，而不是数据。箭头上是"JSON/REST"或"SQL"——而不是"发送用户数据"。数据详细信息属于下一层的序列图。

以下是每个容器如何发挥作用：

CloudFront（边缘/CDN） 位于最前面。来自浏览器的每个请求首先到达CloudFront。静态资源（HTML、CSS、JS、图像）在边缘缓存并直接从S3提供。动态API调用（任何匹配/api/*的内容）被转发到下游。这就是系统全球快速的原因——大多数用户永远不会到达你的源服务器。

API Gateway 接收转发的动态请求。它处理HTTP路由（哪个路径去哪里）、速率限制/节流，并调用Cognito授权器在任何业务逻辑运行之前验证JWT令牌。将它视为Lambda函数的"前门"。

Lambda 包含你的实际业务逻辑——完全无状态且无服务器。它仅在被API Gateway调用时运行，并向DynamoDB读取/写入数据。因为它是无状态的，所以它随需求自动扩展。

Cognito 是身份验证服务。API Gateway在每个受保护的请求上将其作为自定义授权器调用——如果JWT无效或过期，请求在Lambda唤醒之前就被拒绝。

两个数据容器（S3 + DynamoDB） 显示为独立的容器，即使它们是托管的AWS服务——它们仍然是具有自己生命周期、访问策略和扩展行为的独立可部署单元。

虚线箭头表示异步或旁路流（JWT验证、非缓存路由的直接浏览器到API调用）。单击任何容器可进一步探索。