适用于：需要梳理系统数据流向、分析数据加工链路的系统分析师、开发人员、产品经理
结论先行
数据流图（Data Flow Diagram，简称 DFD）是一种描述数据在系统中如何流动、加工、存储的可视化工具。它不关心时间顺序，不关心判断分支，只回答一个问题：数据从哪来、到哪去、中间被谁处理了。
如果你画了很多流程图还是说不清楚"数据在系统里怎么跑的"，你需要的不是更细的流程图，而是一张 DFD。
一、什么是数据流图
数据流图诞生于 1970 年代末的结构化分析运动，由 Edward Yourdon 和 Tom DeMarco 提出，后在企业领域被 Chris Gane 和 Trish Sarson 发展出另一套符号体系。至今仍是系统分析、需求工程、数据架构设计中的经典工具。
DFD 的核心价值：
| 价值 | 说明 |
|---|---|
| 需求清晰 | 逼你在写代码前就搞清楚每个数据从哪来、到哪去、被谁加工 |
| 跨角色沟通 | 非技术人员也能看懂——方框是客户，箭头是数据，不需要懂编程 |
| 边界明确 | 一张上下文图就能说清"系统管什么、不管什么" |
| 逐层分解 | 从全局到细节，一层层拆，不会一上来就陷入细节泥潭 |
| 活文档 | 系统变更后更新 DFD，比翻代码快十倍 |
二、四大核心要素
任何 DFD，无论多简单或多复杂，只用四种符号。
1. 外部实体（External Entity）
数据的来源或去向，存在于系统边界之外。
- 可以是人：客户、管理员、供应商
- 可以是系统：支付网关、邮件服务器、第三方 API
- 又叫"源点/汇点"（Source/Sink）或"终止符"（Terminator）
- 命名用名词，如"客户""银行"
2. 加工/过程（Process）
将输入数据转换为输出数据的处理环节。
- 每个加工必须有至少一个输入流和一个输出流
- 命名用"动词+名词"格式，如"验证订单""计算税费""生成报表"
- 不要用模糊名称如"系统处理"或"数据处理"
- 加工编号：1.0、2.0、3.0（Level 1），1.1、1.2（Level 2），方便跨层级引用
3. 数据存储（Data Store）
数据的停留地点，被动保存，不做加工。
- 可以是数据库表、文件、缓存、消息队列
- 编号用 D1、D2、D3，如"D1: 订单库""D2: 用户表"
- 注意：两个数据存储之间不能直接连线，必须经过加工
4. 数据流（Data Flow）
数据在实体、加工、存储之间的流动通道。
- 用带标签的箭头表示
- 标签必须用名词短语，如"订单详情""支付确认"
- 不能用动词，如"发送订单"是错的——数据流本身是数据，不是动作
- 单向流动：双向数据交换要画两条独立箭头
两种符号体系对比
| 要素 | Yourdon-DeMarco | Gane-Sarson |
|---|---|---|
| 加工 | 圆形（气泡图） | 圆角矩形（上下分隔，上写编号下写名称） |
| 数据存储 | 两条平行线 | 左端开口的矩形 |
| 外部实体 | 矩形 | 方形（带阴影边框） |
| 数据流 | 带标签箭头 | 带标签箭头 |
| 常见场景 | 学术界、软件工程教材 | 企业信息系统、商业分析 |
两种符号表达的信息完全相同，选哪种取决于组织规范。一个项目内必须保持一致，混用会造成阅读混乱。
三、分层结构：DFD 最核心的设计
DFD 最强大的特性是分层分解。你不必在一张图上塞下所有细节，而是从高到低逐层展开。
Level 0：上下文图（Context Diagram）
最高抽象层，将整个系统视为一个加工。
- 恰好一个加工（代表整个系统）
- 显示所有外部实体
- 显示进出系统的主要数据流
- 不包含任何数据存储
- 用途：项目启动时对齐范围，让所有干系人达成共识
示例（在线购物系统上下文图）：
订单详情 订单确认
客户 ──────────→ [购物系统] ──────────→ 客户
│ ↑
支付信息 ↓ │ 支付状态
[支付网关]
发货请求 ↓ ↑ 库存状态
[仓库]
Level 1：主要过程分解
将 Level 0 的单一加工拆解为 3-7 个子加工。
- 引入数据存储
- Level 0 的外部实体必须全部出现
- Level 0 的进出数据流必须全部对应——这叫平衡规则（Balancing）
- 用途：需求评审、设计交接
示例（在线购物系统 Level 1）：
客户 ──订单详情──→ 1.0 管理订单 ──验证订单──→ 2.0 处理支付
↓ 写入 ↓ 读取
═══════════ ═══════════
D1: 订单库 D2: 库存库
═══════════ ═══════════
2.0 处理支付 ──支付状态──→ 3.0 发货通知 ──订单确认──→ 客户
↓ 读取
D1: 订单库
Level 2：详细分解
对 Level 1 中的复杂加工进一步拆解。
- 只对需要进一步细化的加工做分解
- 子加工编号为父加工编号加分号：1.1、1.2、1.3
- 必须与父加工保持平衡（进出数据流一致）
- 用途：实现规格、复杂流程细节
示例（对"2.0 处理支付"做 Level 2 分解）：
支付信息 ──→ 2.1 验证卡片 ──验证结果──→ 2.2 提交扣款 ──扣款结果──→ 2.3 记录交易
↓ 写入
═══════════
D3: 交易记录
═══════════
Level 3：原始图
极少使用，仅当系统极其复杂时才画。大多数项目到 Level 2 就足够了。
判断何时停止分解：如果一个加工能用一段自然语言描述清楚，就不需要再拆。
四、DFD vs 流程图：到底有什么不同
这是最常见的混淆。两者看起来都是方框+箭头，但关注点完全不同。
| 维度 | 数据流图（DFD） | 流程图（Flowchart） |
|---|---|---|
| 关注点 | 数据的流动和转换 | 步骤的顺序和控制逻辑 |
| 时间顺序 | 不建模 | 核心结构 |
| 判断分支 | 不表示 | 明确表示（菱形决策节点） |
| 循环 | 没有 | 有 |
| 数据存储 | 有专属符号 | 不表示 |
| 谁执行 | 不体现 | 可用泳道体现 |
| 适用场景 | 系统分析、数据架构设计 | 流程文档、操作指南 |
一句话总结：流程图告诉你"先做什么后做什么"，DFD 告诉你"数据从哪来到哪去"。
举个例子——同样是"贷款审批"：
- 流程图画的是：申请→审查→（是否通过？）→放款/拒绝
- DFD 画的是：客户→申请数据→审核加工→审核结果→审批记录库→放款加工→放款通知→客户
五、六步绘制法
第 1 步：定义系统边界
用一句话写清楚系统做什么。
例："在线考试系统允许学生参加考试，教师创建试卷，系统自动评分并生成成绩报告。"
这句话直接告诉你：参与者是学生和教师，输入是试卷和答卷，输出是成绩报告。
第 2 步：列出所有外部实体
问三个问题：
- 谁向系统提供输入数据？
- 谁从系统接收输出数据？
- 有没有外部系统与本系统交换数据？
例：学生（提交答卷、接收成绩）、教师（创建试卷、查看统计）、教务系统（接收成绩同步）
第 3 步：画上下文图（Level 0）
- 画一个加工（圆形或圆角矩形），标注系统名
- 把外部实体放在周围
- 用带标签箭头连接，标注数据流名称
- 检查：有没有未标注的箭头？有没有遗漏的实体？
第 4 步：分解为 Level 1
- 将单一加工拆为 3-7 个子加工
- 用动词+名词命名：验证订单、处理支付、发送通知
- 编号：1.0、2.0、3.0
- 加入数据存储，编号 D1、D2
- 连接数据流，每条箭头必须有标签
第 5 步：验证平衡规则
这是最关键的技术规则。
- Level 0 进入系统的数据流，必须在 Level 1 中某个子加工有对应输入
- Level 0 离开系统的数据流，必须在 Level 1 中某个子加工有对应输出
- 如果 Level 0 有"订单详情"进入系统，Level 1 必须有某个子加工接收"订单详情"
第 6 步：按需分解 Level 2
- 只对 Level 1 中足够复杂的加工做进一步分解
- 子加工编号 1.1、1.2、1.3
- 每个 Level 2 图的进出数据流必须与父加工一致
- 当一个加工能用一段话讲清楚时，停止分解
六、五个常见错误
错误 1：把 DFD 当流程图画
在 DFD 里画菱形判断框、循环箭头 → 立刻暴露为新手。DFD 不建模控制逻辑。
正确做法：判断和循环留给流程图，DFD 只画数据流动。
错误 2：数据流不标注
无名箭头在 DFD 中是违规的。每条数据流必须用名词标注。
正确做法：每画一条箭头，立刻写上数据名称。
错误 3：实体直连存储
外部实体直接连到数据存储 → 违反规则。数据必须经过加工才能存储。
正确做法：实体 → 加工 → 存储，中间不能跳过。
错误 4：存储直连存储
两个数据存储之间直接画箭头 → 违反规则。数据必须经过加工才能从 A 库到 B 库。
正确做法：存储A → 加工 → 存储B。
错误 5：跨层级不平衡
Level 0 有"支付信息"进入系统，Level 1 却找不到任何子加工接收"支付信息" → 违反平衡规则。
正确做法：每拆解一层，回头检查进出数据流是否与上层一致。
七、进阶：DFD 在实际工程中的配合使用
DFD 很少单独存在，通常与其他图表配合使用：
| 配合图表 | 组合价值 |
|---|---|
| 上下文图 + ER 图 | 上下文图定义边界，ER 图定义存储结构 |
| Level 1 DFD + 时序图 | DFD 展示数据流向，时序图展示调用顺序 |
| DFD + 流程图 | DFD 理清数据通路，流程图理清操作步骤 |
| DFD + 架构图 | DFD 描述逻辑数据流，架构图描述物理部署 |
| DFD + 鱼骨图 | DFD 定位数据异常节点，鱼骨图分析根因 |
一个实用的文档组合：上下文图（边界）→ Level 1 DFD（数据流）→ ER 图（存储结构）→ 时序图（调用链路），这四张图能覆盖 80% 的系统设计文档需求。
八、工具选择
| 工具 | 优势 | 适合场景 |
|---|---|---|
| singcheng.com | 在线一站式，流程图/架构图/思维导图全覆盖，支持协作 | 日常画图首选 |
| Draw.io（diagrams.net） | 免费开源，符号库丰富 | 个人画图 |
| Visual Paradigm | 专业建模，支持 DFD/UML/BPMN 全系列 | 企业级建模 |
| Lucidchart | 协作友好，模板多 | 团队协作 |
| StarUML | 桌面端，支持扩展插件 | 独立开发者 |
如果只是日常画 DFD，用 singcheng.com 的流程图模块就能搞定——DFD 的四种符号在流程图工具里都能找到对应。如果需要严格遵循 Yourdon 或 Gane-Sarson 符号标准，Visual Paradigm 的模板更完整。
九、自检清单
画完 DFD 后，逐项核对：
符号规范
- 四种符号是否都用到了？
- 是否选定了唯一符号体系（Yourdon 或 Gane-Sarson）且全程一致？
- 加工命名是否都是"动词+名词"？
- 数据流命名是否都是名词短语？
- 数据存储是否都编号了（D1、D2）？
规则检查
- 每个加工是否至少有一个输入流和一个输出流？
- 是否有未标注的数据流箭头？
- 是否有外部实体直接连到数据存储？
- 是否有两个数据存储直接相连？
- 各层级之间是否满足平衡规则？
层级检查
- 上下文图是否恰好一个加工？
- 上下文图是否没有数据存储？
- Level 1 是否拆解为 3-7 个子加工？
- Level 1 的外部实体是否与上下文图一致？
- 是否所有需要细化的加工都做了 Level 2 分解？
- 是否在加工能用一段话讲清楚时停止了分解？
实用检查
- 非技术人员能否看懂上下文图？
- 数据流标签是否足够具体（"订单详情"而非"数据"）？
- 是否有箭头交叉过多（"意大利面"问题）需要重新布局？
- 是否与其他图表（ER 图、时序图）配合使用？
总结
数据流图的核心思路就一句话：别管先做啥后做啥，先把数据从哪来到哪去画清楚。
四步上手：
- 画上下文图锁定边界
- 拆 Level 1 理清主加工
- 验证平衡规则
- 按需深入 Level 2
更多图表绘制教程和实战案例，尽在 singcheng.com ——流程图、架构图、思维导图、原型图、白板，一站式在线画图平台。