做架构评审这些年，我见过太多"画了等于没画"的架构图。最常见的一幕是：一个团队花了三天时间，用专业工具画出一张密密麻麻的框图，箭头横飞、色块堆叠，投到大屏上之后，业务方看不懂，开发觉得没信息量，运维看了直摇头。问题不在于画得丑，而在于画之前没想清楚一件事——这张图到底是给谁看的，要回答什么问题。

软件架构图不是艺术品，也不是文档装饰。它本质上是一种沟通工具，而沟通对象决定了图的类型、粒度和表达方式。业务架构图、应用架构图、技术架构图、数据架构图这四类图，恰好对应四类不同的沟通场景和四类不同的读者。把这四类图混为一谈，或者只画其中一张就宣称"架构图已完成"，是绝大多数架构文档失效的根源。

这篇内容适合正在做系统设计、准备架构评审、或者需要向不同角色解释系统全貌的从业者。不管你是刚接手一个新项目的开发，还是需要向管理层汇报系统现状的技术负责人，下面这套四类图的拆解方法和实操细节，都能直接拿去用。我会把每类图的核心目的、画法要点、常见错误和实操心得讲透，重点放在"为什么这样画"而不是"用什么工具画"。

1. 先搞清楚四类图各自回答什么问题

很多人画架构图的第一步是打开绘图工具，这是本末倒置。正确的第一步是问自己：这张图要回答谁的什么问题？四类架构图之所以要分开画，根本原因是它们服务的读者和回答的问题完全不同。把这个问题想清楚，后面用什么图形、什么颜色、什么粒度，都是自然推导出来的结果。

1.1 业务架构图：回答"系统支撑了哪些业务能力"

业务架构图的读者是业务方、产品经理和管理层。他们不关心用了什么数据库、部署在几台机器上，他们关心的是：这个系统到底覆盖了哪些业务环节，各环节之间是什么关系，哪些能力已经具备、哪些还缺失。

所以业务架构图的核心元素是业务能力和业务流程，而不是技术组件。画的时候应该用业务语言命名，比如"订单履约""会员权益""结算对账"，而不是"OrderService""MemberController"。我见过不少团队把业务架构图画成了应用架构图，满屏都是服务名和接口名，业务方看完一脸茫然，这张图就失去了存在的意义。

一个实用的判断标准：如果这张图拿给一个完全不懂技术的业务负责人看，他能不能在五分钟内指出"我们这块业务在系统里对应哪一块"，能，就是合格的业务架构图；不能，就是画错了。

1.2 应用架构图：回答"系统由哪些应用/服务组成，如何协作"

应用架构图的读者是开发人员、架构师和技术管理者。它要回答的是：系统被拆分成了哪些应用或服务，每个应用的职责边界是什么，它们之间通过什么方式交互。

这里的核心是职责划分和交互关系。一张好的应用架构图，应该能让人一眼看出某个功能应该落在哪个应用里，以及改动一个应用会影响哪些上下游。它关注的是"分而治之"的边界，而不是部署细节。

应用架构图最容易犯的错误是粒度失控。要么拆得太细，几十个服务挤在一张图上，连线像蜘蛛网；要么太粗，一个大方块写着"业务系统"，等于什么都没说。合理的做法是按业务域或限界上下文来组织，一张图控制在十几个核心应用以内，细节用分层或分图展开。

1.3 技术架构图：回答"系统跑在什么技术底座上"

技术架构图的读者是运维、基础设施团队和技术负责人。它关注的是部署形态、网络分区、中间件选型、高可用和容灾策略这些"运行时"层面的东西。

技术架构图的核心元素是部署单元、网络区域、中间件和基础设施。它要能回答：应用部署在几个区域，数据库是主从还是集群，缓存和消息队列放在哪一层，外部依赖有哪些，故障时如何降级。

这类图最忌讳的是把业务逻辑画进去。技术架构图应该只关心"东西跑在哪、怎么连、怎么保障"，一旦开始画业务流程，就说明画串了。我通常建议技术架构图单独成册，和业务、应用图分开维护，因为它的变更频率和变更原因跟另外几类图完全不同。

1.4 数据架构图：回答"数据从哪来、到哪去、怎么存"

数据架构图的读者是数据工程师、后端开发和数据分析人员。它关注的是数据的产生、流转、存储和消费全链路，包括核心数据实体、数据流向、存储选型和数据治理策略。

核心元素是数据实体、数据流、存储介质和数据生命周期。一张合格的数据架构图要能说清楚：核心业务数据有哪些，它们在各系统之间怎么流转，哪些是主数据、哪些是派生数据，数据在哪里落地、保留多久。

数据架构图常被忽略，很多团队画完前三类图就收工了，结果数据口径混乱、重复建设严重。实际上，数据架构图对于排查"这个字段到底以哪个系统为准"这类问题，价值极高。

为了更直观地对比四类图的差异，我把关键维度整理成下表：

这张表建议贴在团队文档的显眼位置，每次画图前对照一下，能避免大部分"画错类型"的问题。

2. 业务架构图：用业务语言把能力边界画清楚

业务架构图是四类图里最容易被轻视、也最难画好的一类。难在它要求画图的人既懂业务又懂系统，还要能把两者对应起来。很多技术出身的人画业务架构图，画着画着就滑向了技术细节，这是通病。

2.1 从业务流程梳理开始，而不是从系统模块开始

画业务架构图的第一步不是打开工具，而是拿一张白纸，把业务流程从头到尾走一遍。比如一个电商履约场景，从用户下单、支付、库存锁定、拣货、发货到签收，每个环节涉及哪些业务动作，这些动作由哪些业务能力支撑。

这个梳理过程建议用业务能力地图的方式组织：把业务按"域—能力—子能力"三层拆解。以交易域为例，下面可以拆出下单能力、支付能力、优惠计算能力，下单能力再往下拆出购物车、订单创建、订单查询等子能力。这样拆出来的结构，天然就是业务架构图的骨架。

我个人的经验是，梳理阶段先不要考虑系统怎么实现，纯粹从业务视角出发。等能力地图画完了，再逐项标注"已实现/部分实现/未实现"，以及"由哪个系统承载"。这个"先业务后系统"的顺序非常关键，反过来做的话，很容易被现有系统的结构绑架，画出来的图只是现有系统的翻版，失去了业务视角的价值。

2.2 分层表达：能力层、流程层、角色层怎么摆

一张完整的业务架构图通常包含三个层次的信息：业务能力（系统能做什么）、业务流程（这些能力如何串起来完成一件事）、参与角色（谁在使用这些能力）。

常见的摆法是横向分层：最上面是角色层，标注用户、运营、客服等角色；中间是流程层，用箭头串起端到端的业务流程；下面是能力层，用方块列出支撑流程的各项业务能力。这种"角色—流程—能力"的三层结构，业务方看起来非常直观，能快速定位自己关心的部分。

也有团队喜欢用"业务域矩阵"的摆法，把能力按业务域分组成网格，每个格子是一个能力，用颜色标注成熟度。这种摆法适合做能力盘点和规划，但不太适合讲流程。具体用哪种，取决于这张图的主要用途——是讲清楚"业务怎么跑"，还是讲清楚"能力有哪些"。两者可以画成两张图，不必强塞进一张。

2.3 业务架构图里不该出现的东西

这一条值得单独拎出来说，因为踩坑的人太多了。业务架构图里不应该出现：具体的技术组件名（如某消息队列、某缓存）、接口路径、数据库表名、部署节点、代码层面的模块划分。

判断方法很简单：图上的每一个名词，业务方能不能听懂。如果出现"Redis""Kafka""微服务"这类词，基本可以判定这张图已经跑偏了。业务架构图的价值在于让非技术角色理解系统，一旦混入技术黑话，这个价值就打了折扣。

还有一个隐蔽的错误是用系统名代替业务能力名。比如图上写"订单系统""库存系统"，这其实是应用架构的表达。业务架构图应该写"订单管理能力""库存管理能力"，强调的是能力而非载体。这个区别看似细微，但它决定了这张图是站在业务视角还是系统视角。

提示：画完业务架构图后，找一个不懂技术的业务同事做"五分钟测试"——让他指出自己负责的业务在图上哪个位置。指不出来，说明图的语言还不够业务化。

3. 应用架构图：把服务边界和依赖关系画明白

应用架构图是技术团队日常用得最多的一类图，也是争议最多的一类。争议的核心永远是粒度：到底拆到多细才算合适？我的答案是，粒度服务于目的——这张图要用来做什么决策，就拆到什么程度。

3.1 按业务域组织，而不是按技术分层组织

很多团队画应用架构图习惯用"表现层—业务层—数据层"的技术分层结构，这种画法在单体应用时代很常见，但在服务化架构下已经不太适用了。技术分层图看不出业务边界，也无法回答"改这个功能会影响谁"。

更实用的组织方式是按业务域分组：把应用按所属业务域聚成几个大块，每个大块内部列出该域下的核心应用或服务，块与块之间画上主要的交互关系。这样画出来的图，业务边界一目了然，也方便做领域划分的讨论。

比如一个交易平台，可以分成用户域、商品域、交易域、履约域、结算域几大块，每块下面挂几个核心服务。域内的高频交互用细线表示，跨域的关键调用用粗线或不同颜色标注。这种"域分组+关键连线"的画法，信息密度适中，既不会太乱，也不会太空。

3.2 交互关系怎么标：同步、异步、强弱依赖要区分

应用架构图里最容易糊弄的就是连线。很多图上一根箭头了事，看不出是同步调用还是异步消息，是强依赖还是弱依赖。这些信息恰恰是排查故障、评估影响时最需要的。

我的做法是给连线加两类标注：交互方式（同步/异步）和依赖强度（强/弱）。同步强依赖用实线粗箭头，异步弱依赖用虚线细箭头，一眼就能区分。如果图面允许，还可以在连线上标注交互的用途，比如"下单校验库存""支付成功通知"。

这样画的好处在实际排障时特别明显。某次线上库存服务抖动，值班同学打开应用架构图，顺着指向库存服务的实线粗箭头，五分钟内就圈定了受影响的调用方，比翻代码快得多。这就是架构图"有用"和"没用"的区别——有用的图能在关键时刻回答问题。

3.3 一张图讲不完就分层，别硬塞

当系统规模上去之后，想用一张应用架构图讲清楚所有服务，几乎不可能。这时候正确的做法是分层出图：一张总览图只画业务域和域间关系，每个域再单独出一张详细图，画到具体服务和接口。

总览图控制在十个左右的域块，详细图控制在每个域十几个服务以内。这种"总览+分域"的两级结构，既保证了全局视角，又保留了细节深度。我见过一些团队非要在一张图上画上百个服务，结果图打印出来有半面墙那么大，实际没人看，纯属自我感动。

分层出图还有个额外好处：不同读者可以各取所需。管理层看总览图，开发看自己所在域的详细图，跨域协作时两张图对照着看。图的维护成本也降低了，某个域内部调整，只需要更新该域的详细图，总览图往往不受影响。

4. 技术架构图：部署形态和保障策略才是重点

技术架构图经常被画成"应用架构图的部署版"，这是个误解。技术架构图的核心不是重复应用之间的关系，而是讲清楚运行时环境：东西部署在哪、网络怎么分区、中间件怎么选型、故障怎么兜底。

4.1 网络分区和部署单元是骨架

一张技术架构图，第一眼应该能看到网络分区。典型的分区包括接入区、应用区、数据区、管理区，不同区域之间用防火墙或网关隔开。每个分区里放对应的部署单元：接入区放负载均衡和网关，应用区放应用集群，数据区放数据库和缓存集群。

把分区画清楚的价值在于，它能直观地回答安全边界和故障隔离的问题。比如"数据库能不能被外网直接访问"这种问题，看一眼分区图就有答案。很多安全评审和等保检查，第一件事就是看这张分区图。

部署单元的画法建议标注实例数量和部署形态，比如"应用集群（3节点）""数据库主从（1主2从）"。这些信息对于容量评估和故障演练非常有用，比单纯画个方块写"应用服务器"信息量大得多。

4.2 中间件和高可用策略要显式标注

技术架构图里，中间件不能只画个图标了事，要标注选型和高可用方式。比如消息队列是单集群还是多集群，缓存是主从还是集群模式，数据库的读写分离和故障切换是怎么做的。

这些信息平时看着琐碎，真出故障时就是救命稻草。我经历过一次缓存集群部分节点故障，值班同学因为架构图上明确标注了"缓存集群模式，单节点故障自动摘除"，很快就判断出影响范围可控，没有盲目扩容。反过来，如果图上只画了个"缓存"图标，就得临时去查配置，耽误时间。

高可用策略还应该包括降级和限流的标注。哪些依赖挂了可以降级，降级后的表现是什么，限流阈值大概在什么量级。这些内容画在图上，等于把应急预案可视化了一部分。

4.3 外部依赖单独成块，别和应用混在一起

系统依赖的外部服务（第三方支付、短信、地图等）建议在技术架构图上单独成块，用不同颜色或虚线框标出，并标注依赖方式和超时策略。这样做的原因是，外部依赖往往是故障的高发区，而且不受自己控制，需要特别关注。

单独成块之后，"哪些外部依赖是强依赖、哪些可以降级"这个问题就变得一目了然。评审时也方便追问：这个外部依赖的超时设了多久，重试策略是什么，对方挂了我们的表现是什么。这些问题在图上有了落脚点，讨论就不会飘。

5. 数据架构图：把数据流转和口径统一画出来

数据架构图是四类图里最容易被跳过的一类，但它解决的问题恰恰是最让人头疼的：数据口径不一致、重复建设、来源不清。一张好的数据架构图，能让"这个数到底以谁为准"这类争论少一大半。

5.1 核心数据实体先盘点，再画流转

画数据架构图的第一步是盘点核心数据实体。什么是核心实体？就是那些跨多个系统使用、有明确业务含义的数据对象，比如用户、商品、订单、账户。把这些实体列出来，标注每个实体的权威来源系统（也就是常说的"主数据源"），这一步就把数据口径的基准定下来了。

盘点完之后再画流转：每个实体从产生到消费，经过哪些系统，在每个系统里是存储还是只读引用，是原样传递还是加工派生。用箭头表示流转方向，用不同线型区分"写入"和"读取"，用标注说明"加工逻辑"。

这个画法能暴露很多隐藏问题。比如经常发现同一个实体在两个系统里都有写入权限，这就是口径冲突的隐患；或者发现某个派生数据被下游当成了权威数据使用，一旦上游加工逻辑变化就会出问题。这些问题不画图很难系统性发现。

5.2 存储选型和数据生命周期要标清楚

数据架构图上，每个核心实体要标注存储介质和保留策略。存储介质包括关系库、缓存、对象存储、搜索引擎等，保留策略包括在线保留多久、归档到哪里、是否脱敏。

这些信息对于数据治理和成本优化都很关键。我见过一个系统，日志类数据在在线库里堆了两年没清理，存储成本高得离谱，问题就在于从来没人从数据生命周期的角度审视过。画数据架构图时把保留策略标上，这类问题就会浮出水面。

5.3 数据流和业务流要能对上

数据架构图和应用架构图之间要能互相印证：应用架构图上的每次服务调用，如果涉及数据写入，应该在数据架构图上有对应的数据流。两张图对不上，往往意味着有隐藏的数据写入路径，或者有没被识别的数据依赖。

我习惯在评审时把两张图并排看，逐条核对关键数据流。这个过程经常能发现一些"野生"的数据写入——比如某个服务绕过主数据源直接写库，或者某个定时任务在偷偷同步数据。这些路径平时藏在代码里，只有画图对照才能揪出来。

6. 四类图怎么协同维护，避免画完就过期

架构图最大的敌人不是画得不好，而是画完就没人管，半年后彻底过期。四类图要真正发挥作用，必须解决维护问题。我的经验是，维护机制比画图技巧更重要。

6.1 建立"变更触发更新"的轻量机制

不要指望定期大扫除式的更新，那种方式坚持不了两个月。更现实的做法是变更触发：当发生特定类型的变更时，强制更新对应的图。比如新增一个外部依赖，必须更新技术架构图；新增一个核心数据实体，必须更新数据架构图；应用拆分或合并，必须更新应用架构图。

把这条规则写进团队的变更流程里，作为提交评审的一项检查项。刚开始可能会觉得麻烦，但坚持下来之后，图的时效性会好很多。关键是触发条件要少而明确，不要搞成"任何变更都要更新所有图"，那样没人执行得下去。

6.2 图要有明确的负责人和版本

每张架构图都应该有明确的负责人和版本记录。负责人不一定是画图的人，但要对这张图的准确性负责。版本记录至少包括修改时间、修改内容和修改原因。

这个要求看似形式主义，实际作用很大。当两个人对系统理解不一致时，翻出图的版本记录，往往能定位到分歧是从哪次变更开始的。而且有了负责人，图的质量就有了兜底，不会出现"人人都能改、人人都不负责"的局面。

6.3 图和文档、代码的三角校验

架构图不能孤立存在，它要和设计文档、代码结构形成互相校验的关系。评审时可以做这样的检查：图上画的每个应用，代码仓库里能不能找到对应模块；图上标的每个外部依赖，配置文件里能不能找到对应配置；图上画的每条关键数据流，代码里能不能找到对应的写入逻辑。

这个三角校验听起来繁琐，但它是保证架构图"说真话"的最有效手段。我见过太多图上一套、代码一套的情况，根源就是画完之后再没和实际实现对过账。定期做一次抽样校验，图的可信度就能维持住。

7. 几个反复踩过的坑和对应的处理办法

最后分享几个我在实际项目中反复遇到的问题，都是些文档里不会写、但实际画图时一定会碰到的细节。

7.1 工具选型别纠结，能协作、能版本管理最重要

关于用什么工具画架构图，我的观点很明确：工具不重要，协作和版本管理才重要。文本化的绘图方式（用代码描述图形）在版本管理上有天然优势，每次修改都能 diff，适合纳入代码仓库一起管理。图形化工具上手快，适合快速沟通，但版本管理往往较弱。

实际项目中我通常两种都用：需要频繁评审和长期维护的核心架构图，用文本化方式画，纳入版本管理；临时沟通用的草图，用图形工具快速画。不要在一开始就追求"统一工具"，那往往是形式大于内容。

7.2 颜色和图例要克制，别让图变成调色盘

架构图用色要克制，一般不超过四到五种颜色，而且每种颜色要有明确含义，并在图例里说明。常见的问题是颜色用得太随意，同一个颜色在不同图里含义不同，读者每次都要重新猜。

我的习惯是固定一套配色语义：比如蓝色表示核心应用，灰色表示外部依赖，绿色表示数据存储，橙色表示需要关注的风险点。这套语义在团队内统一，所有架构图都遵循，读者看多了自然形成条件反射，读图效率会高很多。

7.3 评审时先讲"这张图回答什么问题"，再讲细节

架构评审时，很多人一上来就讲细节，听众还没建立全局认知，很容易迷失。正确的顺序是先花一分钟说明这张图回答什么问题、读者是谁，再展开细节。这个开场看似简单，但能极大提升评审效率。

我通常会在图的一角放一行小字，写明"本图回答：系统由哪些应用组成及主要交互关系；读者：开发与架构评审"。这行字不起眼，但它时刻提醒画图的人和看图的人，这张图的边界在哪里，避免跑题。

7.4 别追求一张图包打天下，该拆就拆

最后一个坑是"一张图情结"——总想用一张图把所有信息都装进去。结果是图越来越复杂，信息密度越来越高，可读性越来越差。架构图的本质是沟通，沟通就要考虑读者的认知负荷。一张图讲清楚一件事，比一张图讲十件事但没人看得懂，价值高得多。

四类图分开画，本身就是对"一张图情结"的纠正。业务、应用、技术、数据各司其职，每张图只回答自己该回答的问题，读者按需取用。这个思路坚持下来，架构文档体系会清爽很多，也更容易维护。

我在实际使用中最大的体会是，架构图的价值不在于画得多漂亮，而在于它能不能在关键时刻被拿出来、被看懂、被用来做决策。四类图各画各的、各管各的，看似增加了工作量，实际上是把沟通成本前置了，长期看反而省事。每次画图前多问一句"这张图给谁看、回答什么问题"，比任何绘图技巧都管用。