最近在做一个跨境支付平台的产品方案，画架构图时遇到两个一直没想清楚的老问题：到底该画哪几张图？每一张又该怎么画才不翻车？
业务架构、应用架构、技术架构、数据架构、部署架构、时序图……模板里这些图五花八门，有的方案只画一张"应用架构"，有的画了十几张。画少了怕评审时被问住，画多了维护不过来；更常见的毛病是图画出来了，可颗粒度忽大忽小、箭头一会儿表示调用一会儿表示数据流，读的人对不上比例尺。
这篇文章把我这次梳理的结论沉淀下来：架构图有哪几套主流体系、本质分工是什么、一份可以直接抄的清单，以及——重点——每一张图具体怎么画好。支付平台只是贯穿全文的例子，方法本身和行业无关。
一、三套主流体系：别混着用
市面上的架构图，基本出自三套体系。很多混乱来自把它们混在一起讨论。
1. 企业架构视角（TOGAF / 国内"4A"）：按领域切
这是国内方案文档（尤其金融行业）最常见的一套，按领域把架构切成四块：
| 类型 | 回答的问题 |
|---|---|
| 业务架构 | 做什么业务、有哪些能力 |
| 应用架构 | 用哪些系统/服务承载这些能力 |
| 数据架构 | 数据怎么产生、流转、消费 |
| 技术架构 | 用什么技术栈/中间件支撑 |
实践中通常在 4A 基础上再加部署架构（多区域、多可用区怎么部）和安全架构（信任域、密钥体系、合规边界），凑成"4+2"。
2. 软件设计视角（4+1 视图 / UML）：按动静切
Kruchten 的 4+1 视图：逻辑视图、开发视图、进程视图、物理视图，外加用例/场景把前四个串起来。我们常画的时序图就属于这里的场景视图——严格说它不是和业务架构、应用架构并列的"分类"，而是把静态架构"动起来"的验证视图。
这套体系现在更多出现在教科书里，实际工程中已经逐渐被 C4 取代。
3. C4 模型：按缩放层级切
C4 不按领域切，按"放大倍数“切：
| |
像地图一样逐级放大：先看系统和外部世界的关系，再看系统内部有哪些服务，再看某个服务内部有哪些组件。近几年它是工程团队的主流，因为每一层都和代码对得上，好维护。
有一块天然的重叠值得注意：企业架构里的"应用架构图”，大致相当于 C4 的 Container 图。这意味着两套体系不必重复画——同一张图在不同阶段加细节就行。
二、本质分工：看场景，不看阶段
两套视角不是"选一种"的关系。真正的判据是这张图画给谁看、撑什么决策——也就是场景，而不是项目走到了哪个阶段：
| 企业架构视角（4A） | 软件设计视角（C4 / 4+1） | |
|---|---|---|
| 回答 | 做什么、为什么、整体怎么布局 | 具体怎么实现 |
| 受众 | 老板、投资人、产品、合规、评审会 | 开发团队自己 |
| 常见阶段（仅相关，非判据） | 立项、方案、规划 | 开发、交接、维护 |
| 变化频率 | 低（季度/年级别） | 高（随迭代演进） |
| 颗粒度 | 系统/能力级 | 服务/模块/代码级 |
一句话：图跟着受众走——
- 给老板、投资人、产品、合规、评审看，撑"建不建、值不值、合不合规"的决策 → 企业架构视角
- 给开发自己看，撑"怎么建、怎么改"的决策 → 软件设计视角
很多人把它记成"早期画企业架构、开发画软件设计"——阶段确实常和场景对应，但那只是相关，不是判据。开发中途来一次合规审计，照样得掏出企业架构那套；立项时碰上技术型投资人，一张 C4 Container 比十页 PPT 管用。所以判断永远回到那一句：给谁看、撑什么决策。拿 C4 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。
怎么画好？ 一张图只讲一个主语，箭头配图例，分层图和流向图别混用。通用清单画完，再检查系统最怕出错的那条流程有没有图能说清，没有就补一张。