在企业技术评审、方案汇报、文档编写中，"架构图"是出现频率极高的交付物。但一个高频问题长期存在：很多人把业务架构、系统架构、技术架构混为一谈，一张图里既画业务模块、又画技术组件，最终谁看了都抓不住重点。
架构图不是一张图，而是一组图。不同阶段的读者、不同层次的决策，需要不同颗粒度的表达。本文从定义、读者、画法三个维度，系统讲透三种常见架构图的区别，并给出可落地的绘制规范与自检清单。
一、先分清：三种架构图回答的是三个不同的问题
| 维度 | 业务架构图 | 系统架构图 | 技术架构图 |
|---|---|---|---|
| 核心问题 | 业务怎么运作？ | 系统怎么组成？ | 技术怎么实现？ |
| 读者对象 | 管理层、业务方 | 产品、研发、运维 | 研发、架构师 |
| 关注点 | 业务流程、组织、价值 | 模块划分、职责边界、依赖关系 | 技术栈、组件、部署、通信 |
| 表达语言 | 业务术语 | 模块名、服务名 | 技术名词、协议、中间件 |
| 典型产出阶段 | 立项、规划 | 概要设计 | 详细设计 |
| 颗粒度 | 最粗 | 中等 | 最细 |
一句话记忆：业务架构讲"做什么"，系统架构讲"怎么分"，技术架构讲"用什么做"。
三者的关系是层层落地的：业务架构定义边界与流程 → 系统架构把业务能力映射为软件模块 → 技术架构为每个模块选定实现方案。三者不是并列的三张图，而是同一系统在不同抽象层的投影。
二、业务架构图：给决策者看的"作战地图"
2.1 定义
业务架构图描述企业或产品的业务能力、业务流程与组织分工，回答"业务如何创造价值"。
2.2 核心要素
- 业务能力域：按业务价值划分的能力集合（如订单域、支付域、用户域）
- 业务流程：跨部门/跨系统的主干流程（常用泳道图表达）
- 组织与角色：谁负责什么环节
- 价值链路：端到端的业务闭环
2.3 绘制要点
- 一张图只表达一层：画能力域，就不要堆流程细节
- 用业务语言命名，禁止出现技术术语（如"MQ""Redis"属于技术架构层）
- 层级不超过三层（能力域 → 子域 → 核心流程），超过则拆分
2.4 高频错误
- 把业务架构图画成系统部署图（混淆层次）
- 追求面面俱到，把全部业务塞进一张图
- 只画结构不画流程，图里看不到"业务是怎么转起来的"
三、系统架构图：给研发团队看的"模块地图"
3.1 定义
系统架构图描述系统的模块/服务划分、职责边界与依赖关系，回答"系统由哪些部分组成、如何协同"。
3.2 核心要素
- 系统/模块边界：每个模块的职责与输入输出
- 依赖关系：模块间调用、数据流、事件流
- 交互方式：同步调用、异步消息、文件交换
- 外部系统：与第三方、遗留系统的边界
3.3 绘制要点
- 一张图表达一个维度：结构视图（谁依赖谁）与交互视图（消息怎么走）分开画
- 依赖方向必须一致且可解释，禁止出现循环依赖的"蜘蛛网"
- 模块命名用领域术语，不写具体类名、表名（那是技术架构的粒度）
3.4 高频错误
- 模块粒度不统一：一个画到服务级，一个画到函数级
- 只画方块不画关系：图变成了"名片墙"，看不出任何结构信息
- 箭头语义混乱：调用、数据流、依赖混用同一种箭头
四、技术架构图：给实现者看的"施工图纸"
4.1 定义
技术架构图描述系统采用的技术组件、部署形态与通信机制，回答"用什么技术、怎么部署、如何保证可用性"。
4.2 核心要素
- 技术栈选型：语言、框架、中间件、数据库
- 部署拓扑：服务器、容器、网关、负载均衡的分布
- 通信协议：HTTP/gRPC/消息队列等交互方式
- 非功能设计：高可用、容灾、监控、安全
4.3 绘制要点
- 明确环境边界：开发/测试/生产环境分开表达
- 数据流向与流量路径要完整标注
- 关键非功能设计（主从、集群、限流）需要单独说明，不能只画静态拓扑
4.4 高频错误
- 技术细节堆砌：把配置参数、版本号全部画进图里
- 只画正常路径，不画异常路径（降级、重试、容灾）
- 与系统架构图混画：一个图里既有服务模块又有具体中间件，两个层次互相干扰
五、组合技巧：用"分层画法"让三种图协同
实践中，三种图不是三选一，而是组合使用。推荐两种成熟做法：
5.1 C4 模型（Context, Container, Component, Code）
Simon Brown 提出的 C4 模型将架构表达分为四层，天然覆盖三种架构图的边界：
| 层级 | 对应类型 | 表达内容 |
|---|---|---|
| C1 系统上下文 | 业务架构 | 系统与外部用户、系统的关系 |
| C2 容器 | 系统架构 | 应用、数据库、消息队列等容器的划分 |
| C3 组件 | 技术架构 | 容器内部的组件与实现 |
| C4 代码 | 细节实现 | 类级别的技术实现（通常不画） |
5.2 汇报场景的组合建议
- 向上汇报（管理层）：只给业务架构图 + 一页技术架构概览
- 跨团队评审（产品+研发）：业务架构 + 系统架构两张图
- 技术评审（研发内部）：系统架构 + 技术架构，必要时补组件图
六、自检清单（发布前逐项核对）
- 是否明确读者是谁？图的语言与颗粒度是否匹配
- 一张图是否只表达了一个维度
- 业务图无技术术语，技术图无业务冗余
- 层级是否超过三层？是否已拆分
- 箭头语义是否统一、方向是否可解释
- 是否标注了图例，颜色是否有语义而非装饰
- 能否用一句话说出这张图的核心结论
总结
架构图的价值不在"画得多"，而在"表达准"。业务架构、系统架构、技术架构分别服务于决策、协同与实现三个层次，混画是评审效率低下的主要原因之一。
先定读者，再定类型；一层图，一个维度；画前想清楚，画后能一句话讲明白。 这是区分专业架构表达与"画方块"的分水岭。