灰色小熊见过太多画得很精致、逻辑却一塌糊涂的数据流图了。之前有一次内部评审，同事放出一张订单系统DFD，方框、圆圈、箭头一个不少，配色也舒服。但我盯了几分钟后问了三个问题：客户档案这个数据存储为什么直接连着“客户”这个外部实体？中间这个只出不进的加工，数据是从哪儿“变”出来的？这条叫“数据”的流到底是订单还是发货单？全场安静了一会儿，然后大家开始逐条补需求。后来整理下来，缺的那些功能，恰恰都藏在被“画飞了”的数据流里。
这就是DFD建模中那四条规则的价值。它来自结构化分析里最经典的一脉，SA方法、Yourdon/DeMarco方法都把它当作建模底线。不管你是软件工程专业的学生、刚入行的需求分析师，还是被分配去画系统现状图的开发，只要你画数据流图，这套规则就绕不过去。它能帮你从“画得热闹”变成“画得对”，也能在项目评审时帮你提前发现需求漏洞。这篇文章不打算复述教科书，我想把它拆开揉碎，从为什么会有四条规则，到每条规则怎么用，再到怎么靠它们去做上下文图逐层分解，一次说清楚。
1. 画了那么多DFD，为什么还是分不清数据流图与业务流程图
1.1 数据流图是“数据加工的蓝图”，不是流程顺序图
很多新手把数据流图画成了带箭头的业务流程图，这是一个很常见的误区。业务流程图的箭头往往表示时间先后、责任岗位流转、判断分支；而数据流图的箭头只有一个含义：数据正在流动，流向哪里、从哪里流出。它不表达“先做什么后做什么”，也不表达“谁通知谁”，更不表达某个数据库表里具体怎么更新。
我经常用一段话解释DFD：它是一张“数据在系统边界内如何被加工”的路线图。数据从外部实体进入系统，经过一个个加工被变换、校验、计算、存储，最终形成结果返回给外部实体。整个过程里，只有四种角色：外部实体、加工、数据存储、数据流。其中“加工”是唯一能修改数据、产生新数据的地方。记住这句话，后面四条规则就顺理成章了。
外部实体是系统外的人、组织或系统，比如“顾客”“财务软件”，是数据的来源或终点。加工是把输入数据变成输出数据的动作，比如“校验订单”“计算总价”。数据存储是静止状态的数据集合，比如“D1订单表”“D2客户档案”。数据流则是正在移动的数据，比如“订单信息”“支付结果”。DFD里不画循环、不画判断菱形、不画时间线，只画数据在这些角色之间的流动。