接上文

三、重点谈三个图

系统架构图、信息图、系统全景图，是我认为最值得下功夫认真打磨的三类图。下面我分别聊聊它们的关键内容。

1、系统架构图

系统架构图解答的问题是：构成系统的组件、组件之间的交互、数据的拓扑结构与流向、系统的边界等。架构图有较多行业标准，其中 C4 模型是目前业界使用最广泛、认可度最高的架构图表达标准，也是最值得学习的。这里不过多介绍相关内容。

我们经常见到的系统架构图，其实是分层系统架构图。这类图主要是结合自己系统所采用的软件架构模式或者范式为基础，来进行丰富填充的。这类范式有分层架构、洋葱架构、六边形架构，还有事件驱动架构、插件架构、微服务架构、云架构。在 C4 模型中 L3 组件图常采用上面的范式架构来绘制，我们经常看到的系统架构图在 C4 模型的标准下只完成了四分之一，虽然是最重要的部分。

对于一个大型系统，从不同的视角看，不同的构件之间的架构不仅仅包含一种架构。一个真正复杂的企业级大型系统，必然是多种架构范式在不同维度、不同层级上的组合与嵌套。架构是个演化的过程，并非一成不变的，我们的架构图体现的是针对某个特定视角的抽象和决策，不可能是面面俱到，更像是某个特定视角的透视切片。所以，使用范式画系统架构图，需要先的界定清楚当前讨论的是哪个视角下，这个视角下是哪种架构范式。当然，我也见过有人将两个” 切片” 合在一起，组成一个信息量更大的架构图。比如某个领域服务是分层架构，但在领域层又采用了插件架构进行拓展，于是把插件架构和分层架构组合到一起，画出了个分层插件架构的系统架构图。

还有一个叫五视图法（4+1 视图），和我们的系统架构图或者 C4 模型其实是相互交叉，并且侧重点不同。其中，场景视图相当于 C4 L1 (System Context) ，也可以使用信息图来呈现；逻辑视图可用 C4 L3 (Component) 来描述，也可用 DDD 领域模型图呈现。进程视图用时序图或者状态机图，开发视图用包依赖图或者代码工程结构图，物理视图用部署与网络拓扑图呈现。

另外，我们常说的架构图其实是个比较泛的概念。按照 4A 架构会分为业务架构、应用架构、数据架构和技术架构这四大类，也就会有四大类架构图。业务架构图不在 C4 核心范围内，更偏向于信息图，图的结构可以更自由的发挥。而后面三种架构图与 C4 模型有互补和关联：应用架构 = C4 L1 (Context) + C4 L2 (Container)；数据架构包含数据标准、数据流向、数据模型等，是 C4 L2 中的存储节点的细化补充，补充了微观的 ER 图或数据血缘关系；技术架构 = C4 L2 / L3 + 部署图，C4 L2/L3 标明了具体的技术栈选型（如 gRPC），而部署图绘制了物理或云端节点拓扑，这两部分组合正好是技术架构关注技术选型、云原生底座、硬件网络。

2、信息图

信息图是个比较泛的概念，将数据、信息或知识的可视化的图都可以是信息图。从这个意义上来说，前文提到的所有图都可以称为信息图。这里我们统一下概念，本文说的信息图排除上文提到的有标准定义的图，比如系统架构图、系统全景图、UML 的各种图，等等。信息图的本质是信息流转、业务逻辑与价值递进的抽象呈现，可以用来解答业务的底层逻辑与运转闭环、数据从输入到输出的加工链条、系统的核心能力层级怎样组织等等传达信息观点的问题。

让人失望的是，这类图并不像架构图一样有标准或者规范，但我们还是可以参考一些日常会用到的范式，大家也可以总结出一套自己的范式。这些范式来源于工作法的信息图，或者从 PPT 或者图表绘制方法中汲取经验，或者参考优秀信息图总结出套路，甚至是文生图模型产出的实例。我这里提几个经常会用到范式：

（1）金字塔 / 分层式结构。常用于技术规划和汇报中的能力模型，类似系统架构图的分层架构，但实际上是能力描述。比如从下至上分为基础设施层、数据沉淀层、核心能力层、业务应用层、终端接入层。这能说清楚能力支撑关系，如我们拥有什么底座，沉淀了什么能力，赋能了什么场景。

（2）价值流 / 流水线结构。常用于大数据平台或者算法落地的数据演进，展示信息是如何从原始状态变为业务价值。如数据源，加工算子，再到决策输出。主要描述状态形态转化，无序的低价值数据，是如何加工为高价值业务动作的。

（3）逻辑飞轮 / 闭环。适用于 PDCA / 反馈类的系统，如营销自动化平台、增长工具、数据闭环系统，主要是描述系统正向增强、闭环反馈，技术模块之间如何相互协同，形成业务自驱动。现在很多 AI Agent 也采用了这个结构来绘制。

（4）矩阵地图 / 二维网格。常用于业务能力矩阵，比如跨部门需求对齐、企业级业务白皮书、对外解决方案。描述全景分类覆盖的能力范围，纵轴按业务域，横轴按能力层级。这样能描述出系统的能力版图有多大，边界在哪里，覆盖了哪些业务。

（5）服务蓝图 / 分层横向泳道。复杂跨端流程（如外卖 / 打车）、端到端体验优化宣讲，都需要一个完整清晰的泳道流程来描述。比如用户触点、到前台互动，再到后台支撑，描述了用户的一个操作，后台跨系统是如何联动支撑的。

此外，还可以用思维导图、鱼骨图、雷达图等等，只要能清楚表述信息，都不是问题。

日常可以根据信息图想表述的核心逻辑，从上面的范式或者日常积累的图中选取一个作为主要结构。而且一张图中的概念最好保持同一个颗粒度，比如能力地图中顶层是智能风控场景，底层应该是多数据源高可用持久化底座，而不应该是 MySQL 数据库。

3、系统全景图

在实际的工程实践中，除了上述的架构图与信息图，系统全景图是大型技术团队（尤其是企业级架构 / 中台团队）不可或缺的核心图表。系统全景图展现企业或大型业务线内，所有应用系统、技术平台及其相互依赖关系的全貌。系统全景图需要回答：到底有多少系统与平台；系统如何按业务域或能力边界划分；关键的数据流与能力依赖在不同大系统之间如何流转；哪些是历史遗留系统，哪些是新建系统；是否存在重复建设的 “轮子” 等。这是一张 “大而全” 的上帝视角技术生态地图。

系统全景图通常采用矩阵式 / 网格化的逻辑布局，主要是二维矩阵结构，原则上是纵向分层、横向分域。纵向按技术与业务栈分层，常见分为：

• 接入 / 触点层： App、小程序、Web、第三方 Open API 等。
• 前台 / 业务应用层： 营销系统、订单系统、客服系统等。
• 中台 / 核心服务层： 用户中心、支付中台、履约中台等。
• 数据与 AI 层： 数仓、实时计算、数据湖、大模型服务平台等。
• 基础设施与 Pass 层： K8s 集群、消息中间件、监控告警、CICD 管道等。

横向按业务板块或能力边界划分列，例如供应链域、用户营销域、结算风控域、公共服务域等。当然，某一层可能需要按多个维度划分，于是出现嵌套层；而某一层也可能不适合继续细分，于是出现 “没有列” 的情况。

系统全景图描述是粗颗粒度的系统信息，需要收敛到 “系统 / 应用级”，节点必须是 “系统”（如订单中心、Kafka 集群），严禁出现具体的代码模块、类名或数据库表。其次是抽象流向，减少连线。除非是跨域的核心主干链路（如 “订单到支付”），否则不画细粒度的点对点连线。连线过多时，改用 “归属关系”（将系统放入对应的域 / 层方框中）来隐式表达关系。

当然，除了矩阵布局的主图外，可以采用中心辐射型 / 三段式布局，也就是主图居中，两侧摆放辅助或关联模型，呈现出的对称布局。如果内容不足以两边摆放，也可以只留一边，呈现出半对称布局。于是就有了下面几种结构化的模式：

（1）业务价值流：左输入、右输出。从左向右自然阅读，表达 “输入原始数据 / 需求 $\rightarrow$ 中间核心加工 $\rightarrow$ 右侧产出业务价值”。比较适合向上汇报与产品对齐。

• 左侧【输入模型 / 触点层】：可以是用户触点 / 接入模型（ App、小程序、H5、第三方 Open API、IoT 设备接入等），上游数据 / 业务源模型（原始日志、外部供应商数据、外部支付网关、前端行为事件流）
• 中间【核心系统 / 平台】：核心计算引擎、业务逻辑处理、状态机编排、核心数据库
• 右侧【输出模型 / 消费层与价值落地点】：可以是下游消费模型（结算中心、履约系统、数据仓库 / 数据湖、报表 / BI 仪表盘），业务价值落地点（ 自动化营销推送、风控拦截动作、客户服务工单、决策支持）

（2）能力与支撑：左上游、右支撑。表达中间的核心业务是如何向上承接多元场景，向右复用企业公共基础设施的，比较适合平台 / 中台设计宣讲。

• 左侧【上游业务 / 前台场景模型】：具体的业务场景模型（如：直营电商、加盟店业务、O2O 履约、跨境业务）。
• 中间【核心业务能力 / 中台】：该业务的核心领域模型（如：商品域、订单域、库存域、履约域）。
• 右侧【横向公共支撑 / 中台能力模型】跨业务线共享的底层能力（如：统一用户 / 账号中心、支付结算中台、统一消息中心、电子签章服务）。

（3）生命周期：左开发交付、右运维监控。表达左边负责把代码安全上线到中间，右边负责监控与保障中间系统的稳定运行。是运维与生命周期视角，特别适合中间的核心图是系统的运行时逻辑架构（L2 Container / 微服务拓扑），常出现在技术架构与安全评审。

• 左侧【开发与交付模型】：代码仓库（Git）、CICD 编译构建管道、自动化测试套件、镜像仓库、配置中心发布管控。
• 中间【运行时核心架构】：网关、微服务集群、缓存、消息队列、主数据库拓扑。
• 右侧【运维、监控与安全模型】：可观测性模型（监控平台、链路追踪、ELK 日志中心）；安全与容灾模型（ 统一 IAM 鉴权、密钥管理、防火墙、异地多活 / 灾备切换控制）。

（4）治理与规范：左现状与演进、右标准和规范。这个时候中间的核心图一般是某个正在建设的 “目标态架构”

• 左侧【现状与演进模型】遗留系统、逐步替换的旧数据库、过渡期数据同步双写模型。
• 中间【目标态核心架构】新设计的微服务与云原生底座。
• 右侧【技术标准与规范模型】技术选型白名单（允许使用的语言、中间件）、接口规范（REST/ProtoBuf）、数据安全与合规标签（PII 加密规范）。

四、一些建议和观点

1、日常需求画哪些图

• 日常中小型需求：“三视图”。逻辑视图（模块改动）、进程视图（关键接口时序）与 开发视图（代码改动范围）。
• 大型重构 / 核心平台建设： 五视图必有，C4 系统架构图按需。在技术方案设计文档，必须有五视图，确保在性能、安全、部署、业务能力和代码规范上无死角。

2、老板需要的图很大的作用是汇报

• 一张好图的运用场景可以用在自己汇报给老板，也可能是老板向上汇报，还可以做影响力输出。
• 汇报是向上争取资源的一种高效方式。如果在技术岗位上希望获得更多资源与支持，画出一张高质量的图，是一项很 “硬” 的能力。
• 不要本末倒置了。画图是为了传达信息，辅助澄清问题或者展示成果，不代表图画的好实际就能有好的业务效果，更不能拿一张主要汇报用的图去做落地，落地还是需要严谨的系统架构图。

3、AI 时代不擅长画图还有选择

• AI 时代如果不擅长画图，就一定得擅长写作，你把需要的图、文档和目的用自然语言清楚的描述，AI 也能文生图。
• 以前出一个高分的信息图，经常是需要业务、研发、美工等多个岗位合作产出。现在可以借助 GPT Image 或者 Nano Banana 来绘制出各种信息图，skillhub 市场里也不乏拿来即用的 skill，比如 @user_04c33885/diagram-builder。