架构图到底该画哪几张、怎么画？——从 4A、C4 到一份可抄的九张图清单

Thu, 11 Jun 2026 20:00:00 +0800

最近在做一个跨境支付平台的产品方案，画架构图时遇到两个一直没想清楚的老问题：到底该画哪几张图？每一张又该怎么画才不翻车？

业务架构、应用架构、技术架构、数据架构、部署架构、时序图……模板里这些图五花八门，有的方案只画一张"应用架构"，有的画了十几张。画少了怕评审时被问住，画多了维护不过来；更常见的毛病是图画出来了，可颗粒度忽大忽小、箭头一会儿表示调用一会儿表示数据流，读的人对不上比例尺。

这篇文章把我这次梳理的结论沉淀下来：架构图有哪几套主流体系、本质分工是什么、一份可以直接抄的清单，以及——重点——每一张图具体怎么画好。支付平台只是贯穿全文的例子，方法本身和行业无关。

一、三套主流体系：别混着用

市面上的架构图，基本出自三套体系。很多混乱来自把它们混在一起讨论。

1. 企业架构视角（TOGAF / 国内"4A"）：按领域切

这是国内方案文档（尤其金融行业）最常见的一套，按领域把架构切成四块：

类型	回答的问题
业务架构	做什么业务、有哪些能力
应用架构	用哪些系统/服务承载这些能力
数据架构	数据怎么产生、流转、消费
技术架构	用什么技术栈/中间件支撑

实践中通常在 4A 基础上再加部署架构（多区域、多可用区怎么部）和安全架构（信任域、密钥体系、合规边界），凑成"4+2"。

2. 软件设计视角（4+1 视图 / UML）：按动静切

Kruchten 的 4+1 视图：逻辑视图、开发视图、进程视图、物理视图，外加用例/场景把前四个串起来。我们常画的时序图就属于这里的场景视图——严格说它不是和业务架构、应用架构并列的"分类"，而是把静态架构"动起来"的验证视图。

这套体系现在更多出现在教科书里，实际工程中已经逐渐被 C4 取代。

3. C4 模型：按缩放层级切

C4 不按领域切，按"放大倍数“切：

1

Context（系统上下文）→ Container（容器/服务）→ Component（组件）→ Code（代码）

像地图一样逐级放大：先看系统和外部世界的关系，再看系统内部有哪些服务，再看某个服务内部有哪些组件。近几年它是工程团队的主流，因为每一层都和代码对得上，好维护。

有一块天然的重叠值得注意：企业架构里的"应用架构图”，大致相当于 C4 的 Container 图。这意味着两套体系不必重复画——同一张图在不同阶段加细节就行。

二、本质分工：看场景，不看阶段

两套视角不是"选一种"的关系。真正的判据是这张图画给谁看、撑什么决策——也就是场景，而不是项目走到了哪个阶段：

	企业架构视角（4A）	软件设计视角（C4 / 4+1）
回答	做什么、为什么、整体怎么布局	具体怎么实现
受众	老板、投资人、产品、合规、评审会	开发团队自己
常见阶段（仅相关，非判据）	立项、方案、规划	开发、交接、维护
变化频率	低（季度/年级别）	高（随迭代演进）
颗粒度	系统/能力级	服务/模块/代码级

一句话：图跟着受众走——

给老板、投资人、产品、合规、评审看，撑"建不建、值不值、合不合规"的决策 → 企业架构视角
给开发自己看，撑"怎么建、怎么改"的决策 → 软件设计视角

很多人把它记成"早期画企业架构、开发画软件设计"——阶段确实常和场景对应，但那只是相关，不是判据。开发中途来一次合规审计，照样得掏出企业架构那套；立项时碰上技术型投资人，一张 C4 Container 比十页 PPT 管用。所以判断永远回到那一句：给谁看、撑什么决策。拿 C4 Component 图给投资人讲会把人讲睡着，拿业务架构图指导开发则什么也指导不了。

flowchart TD
 A[要画架构图了] --> B{画给谁看?}
 B -->|老板 / 客户 / 评审 / 合规| C["企业架构视角
业务 + 应用 + 部署（+数据/技术/安全）"]
 B -->|开发团队| D{要画多深?}
 D -->|整体服务划分| E["C4 Context + Container
（Container 可由应用架构图细化而来）"]
 D -->|单个服务内部| F["Component + 状态机 + 异常时序图"]

三、实践中的典型组合

实际项目几乎没人把两套画全（4A 四张 + 安全 + 部署 + C4 四层 + 4+1 五视图 = 十几张，没人维护得动）。常见的节奏是：

方案/立项期：企业架构套餐（业务/应用/数据/技术/部署）+ 一两张关键场景时序图
开发启动期：补 C4 的 Context 和 Container——Container 直接从应用架构图细化，标上技术栈、通信协议、同步/异步，不用另起炉灶
开发进行中：每个核心服务按需画 Component 图、状态机图、关键链路时序图
长期维护：只保鲜 Container 层和状态机，更细的图让它随代码文档化

不同团队的"默认选择"也不一样：

互联网产品/创业团队：通常只画两三张——一张"应用架构图"（其实是 4A 和 C4 Container 的混血）+ 部署图 + 关键时序图，不讲究流派，够用就行
金融/银行/大厂中台：企业架构 4A 是规定动作，方案评审模板就长那样
乙方/咨询公司：几乎全是企业架构视角，因为受众永远是客户的决策层
纯工程团队：C4 是主流

四、画好每一张图的四条通则

选对体系只解决了"画哪几张"，更容易翻车的其实是"每一张怎么画"。下面四条通则和图的类型无关，是我踩坑总结出来、贯穿后面所有示例的底层规矩。

通则一：一张图只讲一个主语、一个抽象层级。 最常见的翻车是颗粒度不一致——同一张图里，左边画到"系统级"（订单系统），右边却画到"类级"（OrderValidator），读者瞬间失去比例尺。动笔前先定一句话：“这张图的最小单元是系统、是服务、还是组件？“定了就不破例。

通则二：箭头必须有统一且显式的语义。 一张图里的箭头如果一会儿表示调用、一会儿表示数据流、一会儿表示依赖，就等于没画。把规则固定下来——实线/虚线、实心/空心、同步/异步各代表什么——并在角落放一个图例（legend）。后面资金流图里"实线＝资金划拨、虚线＝逻辑记账"就是这条的应用。

通则三：分层图和流向图是两种语法，别揉在一起。 技术架构图那种上下分层，表达的是"谁依赖谁”（上层依赖下层），不是调用顺序，所以图里不该有回头箭头；数据架构图、时序图那种从左到右，表达的才是"流动方向”。把分层图画上一堆来回箭头、或把流程硬塞进分层结构，都是把两种语法揉到一起。

通则四：通用清单画完，再问一句"这个系统最怕什么出错"。 上面那套通用图有个共同点：画的几乎全是"信息怎么走"。但一个项目最关键、最怕错的那条流程，未必落在这套表达能力之内。画完之后停一下，想想这个系统最致命的失败模式是什么，如果现有的图都答不上来，就为它单独补一张。这张按需补的图，我称之为"领域关键流图"——画本领域最怕出错的那条流。我这个支付方案就是如此：标准八张图画完，没有一张能回答"钱怎么走、此刻在谁名下、哪条是监管红线"，于是补了第 9 张——支付领域的关键流图就是资金流图（详见第六节）。补图的判断只有一条：已有的图表达不了那条最该说清的流程。

五、一套可以直接抄的清单

最后给一个我这次实际落地的清单，单个 drawio 文件、9 个 Sheet，供做方案的同学参考：

#	Sheet	体系归属	一句话用途
1	系统上下文图	C4 Context	给非技术干系人看的第一张图：我们和世界的关系
2	业务架构图	4A	业务能力地图
3	应用架构图	4A ≈ C4 Container	服务划分，开发期直接细化复用
4	数据架构图	4A	数据采集 → 数仓 → 应用的流向
5	技术架构图	4A	技术栈分层
6	部署架构图	4A 扩展	多区域多可用区、灾备
7	安全架构图	4A 扩展	信任域、密钥体系、合规边界
8	时序图	4+1 场景视图	核心链路动态验证
9	领域关键流图	清单外按需补充（通则四）	本领域最怕出错的那条流程；本文例子里是资金流图

不必九张全画——方案早期画 1、2、3、6 四张就能撑起一场评审；其余的按受众追问的方向补。

六、把九张图完整画一遍（脱敏示例）

光给清单不给图等于没说。下面以一个虚构的跨境支付平台为例，把九张图完整画一遍——重点不在支付，而在每张图怎么落笔、第四节那四条通则具体长什么样。全部用 draw.io 绘制后导出 SVG，点开可看原始大图。第二节那种简单示意用 Mermaid 足够，但这种分层全景图，还是 draw.io 这类画布工具才控制得住布局。

1. 系统上下文图：我们和世界的关系

画法： 把"我们的系统"画成正中央一个框，绝不展开内部；外部的人和系统环绕四周，箭头只标"谁发起、为了什么"。画这张图的纪律是克制——任何想往中间那个框里加细节的冲动都要忍住，那是 Container 图的事。给非技术干系人讲方案，从这张开始。

2. 业务架构图：业务能力地图

画法： 用分块/分层把能力堆起来，一个技术词、一个系统名都不该出现——出现了就说明你画串到应用架构去了（通则一里的"主语"跑偏）。检验方法：把图丢给业务方看，他们能全部读懂才算合格。

3. 应用架构图：服务划分（≈ C4 Container）

画法： 全图保持同一颗粒度（都画到"服务"这一层，别一个框是系统、一个框是类）。开发启动后，往每个框上补技术栈、通信协议、同步/异步，这张图就升级成了 C4 Container，可以直接用，不必重画。

4. 数据架构图：数据的一生

画法： 按数据的生命周期从左到右排——采集 → 存储/数仓 → 消费，箭头表示流向（这是流向图，不是分层图）。画的时候别漏掉"非分析型"的消费方：在这个支付例子里，对账引擎和监管报送就和 BI 并列，都是一等公民，而不是附属品。

5. 技术架构图：技术栈分层

画法： 这是典型的分层语法（通则三）——上下表示依赖层次而非调用顺序，所以图里不该出现回头箭头。每个系统的层数按需增减：这个支付例子就比一般系统多了"区块链层"和更重的密钥安全组件。

6. 部署架构图：怎么部、怎么活下来

画法： 把评审必问的三件事直接标到图上，让图自己回答读者的问题——单点在哪（最好是"没有"）、数据怎么不丢（跨 AZ + 异步复制）、挂了怎么切（DNS 切流）。读图人想问的，图上已经写着，评审就顺。

7. 安全架构图：信任域与红线

画法： 信任域用嵌套的框来画——框套框，越往里信任级越高，红线就是框的边界。核心思想一行字：纵深防御 + 最小权限。在这个支付例子里，卡 Vault、MPC 这类最敏感的组件，就要落在最里层的隔离区。

8. 时序图：核心支付链路动起来

画法： 时序图的价值不在把流程画顺，而在顺手标注工程约束——哪一步要幂等、哪一步是异步回调、回调丢了靠什么兜底。把这些标上，这张图就成了静态架构的"验收测试"；不标，它就只是一张谁都会画的步骤图。

9. 领域关键流图（本例：资金流图）：钱在谁名下

这就是第四节通则四说的"领域关键流图"落到支付领域的实例——资金流图：三条入金路径汇入监管账户，再分流出金：

画法： 节点换成本领域的关键实体、连线换成那条最怕出错的流，本质上就是一张流程图。画的时候注意三点：箭头语义要显式（通则二），用实线/虚线区分"实际发生的转移"和"逻辑记录、可选路径"；分清物理实体和逻辑实体，逻辑实体并不真实存在，图上要交代它靠什么和物理实体核对一致；涉及合规、隔离、一致性的边界要明确画出来，不能只靠口头说明。换个领域，这张图会叫不同的名字：支付是资金流图，电商是库存与履约流图，IM 是消息投递链路图，IoT 是设备状态流转图，画的都是本系统最怕出错的那条流程。

结语

回到开头的两个问题。

画哪几张？ 看这张图给谁看：给老板和评审，用企业架构那套；给开发自己，用 C4。

怎么画好？ 一张图只讲一个主语，箭头配图例，分层图和流向图别混用。通用清单画完，再检查系统最怕出错的那条流程有没有图能说清，没有就补一张。

架构图 on 牛哥聊技术