如果你在互联网公司干过三年以上，一定见过这种场景：
会议室里，投影仪打出一张密密麻麻的业务架构图。方框套方框、箭头缠箭头、每个节点下面还塞了三四行小字。主讲人激情澎湃地讲了二十分钟，下面的人已经在偷偷刷手机了。
散会后，没有人真正理解那张图在说什么。
这不是架构的问题，是架构图的问题。
我在两家大厂做了十几年后端开发，从画给自己看的技术架构，到画给老板看的业务蓝图，再到画给投资人看的战略全景，各种场景的架构图都画过。踩过的坑、挨过的骂、返过的工，让我慢慢悟出一个道理：
架构图不是信息堆砌的工具，而是信息筛选的艺术。 画架构图最大的能力不是"画"，是判断什么不该画。
下面这六条原则，每一条都是我用加班和重画换来的教训。
第一条：先搞清楚"给谁看"
这是最基础也最容易被忽略的一条。
同一套业务系统，面向不同的人，架构图应该是完全不同的东西：
- 给技术团队看：关注模块边界、数据流向、接口契约、技术栈选型。可以出现中间件名称、数据库类型、通信协议。
- 给业务方/产品看：关注能力边界、业务流程、系统间协作关系。技术细节全部隐去，用业务语言代替技术术语。
- 给老板/投资人看：关注战略定位、核心壁垒、价值闭环。一张图不超过 10 个核心模块，每个模块一句话讲清楚价值。
我犯过的经典错误：给CEO汇报时，架构图里出现了"Kafka集群"和"Redis哨兵模式"。老板看着这两个词的表情，我到现在都记得。
判断标准：画完之后找目标用户看30秒，如果30秒内对方能说出这张图在讲什么，及格。说不出，重画。
第二条：卡死三层，别贪多
一张好的业务架构图，最多承载三个信息层级。超过三层，人的大脑处理不过来，信息密度崩溃。
我自己的铁律：
层级 | 承载内容 | 视觉权重 |
核心域 | 业务主干：核心能力、核心流程、核心数据 | 最大、最显眼、颜色最重 |
支撑域 | 辅助能力：配置管理、监控告警、权限体系 | 中等尺寸、浅色 |
外围域 | 外部依赖：第三方服务、数据源、用户触点 | 最小尺寸、灰色调 |
超过三层怎么办？拆成多张图。 宁可画三张清晰的图，也不要画一张没人看得懂的图。一张图讲一件事，不要指望一张图把所有信息都装进去。
第三条：箭头不是装饰品，每一条线都代表一个承诺
很多架构图里，箭头画得特别随意——想到什么连什么，画完才发现整个图上全是交叉线和蛇形走位。
每一条连线都在告诉读者一个明确的信息：
- 实线箭头：数据/请求的流向，"A 依赖 B"
- 虚线箭头：间接关系，"A 受 B 影响"或"A 感知 B 的状态"
- 双向箭头：双向通信（慎用，双向箭头往往说明边界还不够清晰）
- 无箭头的线：关联关系，没有明确的依赖方向
实用原则：
- 减少交叉：交叉线是架构图可读性的头号杀手。如果出现了超过两处交叉，说明布局需要重新规划。
- 同一个方向的线走一起：同方向的线束尽量平行排列，形成"数据流通道"，让人的视线自然跟着走。
- 图例不要省：线的含义、颜色的含义、形状的含义，花5秒钟在图下方加一行图例，能让阅读效率提升一倍。
第四条：形状是有语义的，别乱用
很多人画架构图时，矩形、圆角矩形、圆形、菱形混着用，觉得"好看就行"。但读者会在潜意识里把形状和含义绑定：
- 矩形：系统/模块/服务。最中性的形状，代表一个独立的功能单元。
- 圆角矩形：产品/应用层的东西，比矩形"软"一点，通常代表面向用户的东西。
- 圆形/椭圆：用户/角色/外部参与者。
- 菱形：决策节点（流程图专用，架构图中少用，容易混淆）。
- 六边形：端口/适配器。在六边形架构中特指领域驱动设计中的端口概念，不要混用语境。
- 圆柱体：数据库/持久化存储。
一旦定了某形状代表什么，同一张图里不要换。如果矩形一会儿代表服务，一会儿代表数据库，读者会疯。
第五条：颜色克制，三色原则
业务架构图不是彩虹，颜色越少，信息越清晰。
我自己的"三色法则"：
- 主色（一个）：核心模块的标准色。比如所有业务模块统一用一种颜色。
- 对比色（一个）：关键路径、重点标注用。比如最核心的那条数据流线。
- 中性色（灰/白/浅色）：所有非核心信息。辅助模块、外部依赖、备注文字全用中性色压低视觉权重。
超过三种颜色的架构图，要么是设计师在做品牌物料（那是另一个场景），要么就是不会做信息分层。
附加原则：不要用颜色区分业务含义，用位置和分组区分。颜色只用来控制视觉权重——告诉读者"先看这里，再看那里"。
第六条：给每一张图写一句话
这是我近几年养成的最有用的习惯。
画完一张架构图之后，在图的右上角写一句话：
"这张图想说明的核心结论是：______"
如果你写不出这一句话，说明你自己都没想清楚这张图要表达什么，那读者更不可能看懂。
这句话对你自己来说是校验，对读者来说是导航。读者看完这句话就知道该从哪个角度理解这张图，阅读效率直接翻倍。
一个真实的例子
去年我带一个新项目，需要向业务方解释"用户增长系统"的技术架构。
第一版（给自己人看的）：画了完整的技术架构，包括数据接入层、ETL流水线、实时计算引擎、用户画像存储、触达通道管理、AB实验平台。密密麻麻，自认为很专业。
业务方看完：沉默。
第二版（改过之后）：只保留四个核心域：
- 数据采集——"我们拿到了什么"
- 用户洞察——"我们知道了什么"
- 策略引擎——"我们决定做什么"
- 触达通道——"我们怎么做"
技术细节全部隐藏到每个域的"展开"层级（如果有需要可以单独展开一张子图）。整张图12个模块、8条连线，业务方能在一分钟内讲给别人听。
这就是从"技术炫耀型架构图"到"沟通导向型架构图"的转变。
总结：六条铁律
- 先确定读者：给技术、给业务、给老板，是三张完全不同的图
- 三层封顶：核心域→支撑域→外围域，超过就拆
- 每一条线是承诺：搞清楚关系的语义，管好交叉
- 形状有语义：定了就别改
- 三色克制：一个主色+一个对比色+中性色
- 一句话总结：写不出核心结论，说明没想清楚
画架构图本质上是在做"信息翻译"——把你脑子里复杂的系统认知，翻译成读者能在30秒内理解的可视化语言。
翻译得好不好，不取决于你的技术有多深、画的图有多复杂，而取决于你有多理解读者，有多克制自己的表达欲。
下一次打开画布之前，先问自己三个问题：
- 这张图是给谁看的？
- 他最关心什么？
- 什么东西他不需要知道？
想清楚这三个问题，架构图已经成功了一半。