Data Flow Diagrams（数据流程图）：业务逻辑的“透视眼”-CSDN博客

本文链接：https://blog.csdn.net/m0_49044890/article/details/147889748

让数据在系统间的流动一目了然。

在一次流程优化项目中，客户总觉得某一步“总是慢”，但问他们为什么慢，没人能说清楚。我画了一张 Data Flow Diagram（数据流图），不到 30 分钟，整个项目的问题“透明了”。

有时候，业务流程就像一栋楼的水管系统，看不见流动的路径，只能靠感觉“哪里堵了”。

Data Flow Diagram，就是 BA 的“透视眼”，帮你看清数据从哪儿来、去哪儿、在中间经历了什么。

让数据流动图可视化，让每个人看到同一个世界。

它不是流程图，也不是系统架构图，更不是简单画框框，而是专注于**“数据是怎么流动的”**。

一句话解释：

DFD 就是把业务流程抽象成“数据”在“实体”、“系统”和“存储”之间流动的过程图。

它关心的是：

它是：

一句话：用最直观的方式，呈现数据在系统中的流动和处理。

确定系统边界 明确谁是外部实体（如用户、第三方系统）？系统自身处理到什么程度？
识别数据流
- 外部实体与系统之间交换了哪些数据？
- 系统内部各个处理步骤之间传递了什么信息？
定义数据存储
- 哪些地方需要暂存或持久化数据？（如数据库、文档存储）
绘制核心元素
- 外部实体（方框表示）
- 数据流（箭头表示）
- 处理过程（圆形或椭圆形表示）
- 数据存储（平行线表示）
逐层分解（Leveling）
- 从高层（概览）到低层（细节），逐步展开，保持清晰
- 为每个 Process 编号与命名（如 P1：验证客户信息），便于多层级之间追踪。
- 注意各层数据流的平衡关系，即子图与父图的数据流输入输出需保持一致。
验证与迭代
- 和业务、技术团队反复确认，确保没有遗漏或误解

某公司投诉“报表数据总是错的”，IT 说“系统没问题”，业务说“那就是你没懂我”。

我画了一张 DFD，发现：

谁也没错，错在流程没画清楚，数据流盲区。

保持简洁，不要试图在一个DFD里塞下所有细节，分层表达更清晰。
强调数据流向，方向箭头必须准确，体现真正的数据传递路径。
不要混淆“控制流”和“数据流”，DFD只关注数据本身的运动，它不用于展示用户行为顺序或决策分支，适用于建模信息流与数据处理过程，而非控制流程。
DFD（数据流图）通常与用例图（定义系统功能边界）、活动图（展示用户或系统行为流程）协同使用，从功能、流程、数据三个角度，构建完整的业务逻辑视图。同时，它也常与实体关系图 ERD（表达数据结构）结合使用，分别从信息流动与数据结构两个维度，全面刻画系统的处理机制与数据组织。
多走访、多提问，通过对话确认数据流动的真实路径，而非想当然推测。
让非技术人员也能看懂，真正的好图，是一眼就能明白的。