画数据流图这件事我刚开始入行那几年是真没当回事觉得不就是几个框框加箭头嘛。直到有一次接手一个老系统做功能迁移折腾了整整一周理不清业务边界最后是老同事丢过来一张泛黄的数据流图十分钟我就知道数据从哪进来、经过哪些处理、存到哪去。从那以后我自己画任何系统设计图第一张永远先画数据流图。这东西看起来简单但真能画得规范和有用的比想象中少得多。这篇就围绕数据流图的画法把上下文图、分层分解、加工与存储的细节、查询修改这类典型场景以及我自己踩过的坑一次性讲透。适合正在学软件工程的学生、刚转行做需求的同学以及明明画了图但总被开发吐槽看不懂的产品和测试。1. 数据流图是啥四个要素和它解决的核心问题数据流图Data Flow Diagram简称DFD描述的是数据在系统里怎么流动、怎么被加工、存在哪里它完全不关心谁在操作、什么时候操作。你可以把它理解成一张数据物流地图货物就是数据仓库就是数据存储加工车间就是处理逻辑发货方和收货方就是外部实体。1.1 四个基本要素比你想的简单数据流图一共就四样东西别被各种教材里花里胡哨的符号吓到。外部实体在系统外面但跟系统有数据往来的角色比如用户、银行、供应商。一般用矩形框表示可以画阴影区分。外部实体是系统的边界数据从它这里进入系统处理完再回到它手里。加工Process对数据做的事比如验证账号计算运费生成订单。用圆角矩形或圆形表示必须有一个动词开头的名字必须能说出它做了什么操作。数据存储Data Store数据待着的地方数据库表、文件、缓存都算。用两条平行线开口矩形表示名字用名词比如订单表用户缓存。数据流Data Flow一条带箭头的线代表一份数据从一处到另一处。名字必须是个名词比如订单信息查询条件箭头方向就是数据流动方向。这四样放在一起就能完整回答三个问题系统跟谁打交道实体、系统做什么加工、做的时候数据怎么进怎么出数据流和存储。我在实际画图时最深的体会是这四个要素的命名一旦规范整张图的信息量立刻翻倍。1.2 数据流图和流程图、ER图有什么区别很多新手把数据流图画成了流程图这是最大的误区。流程图描述的是做什么事情、按什么顺序做强调的是控制逻辑和步骤顺序里面的箭头是流转带着时间先后。数据流图的箭头是数据本身在流动不包含任何顺序含义甚至不应该出现如果否则循环这类控制逻辑。ER图描述的是数据之间有什么关系强调的是静态结构。数据流图描述的是数据怎么在路上走强调的是动态行为。这三者的关系我一般这样跟团队解释先有数据流图理清业务脉络再从数据流图里提炼出需要存储的数据结构画ER图最后才针对每个加工画流程图实现。顺序反了基本都会返工。我自己就吃过亏有次先画了精密的ER图结果发现业务流程根本走不通又回头重画数据流图才找到问题——数据表设计得再好也得先让数据按业务流起来。2. 画图之前必须先搞懂的分层套路数据流图最核心的画法不是在一个图层里把所有东西画出来而是分层——这也是很多教材强调的自顶向下逐层分解。为什么非要分层因为真实业务系统不可能一张图画完硬画的结果就是线条交叉、信息爆炸谁看了都头大。分层的思路跟看地图一模一样先看整个城市再看各区最后放大到街道。数据流图通常分三层就够了。2.1 上下文图一张图装下整个系统上下文图也叫顶层图是整套数据流图的第0层。这一层只有一个加工代表整个系统把系统看成一个黑盒只画外部实体和系统之间的数据流。它回答的问题是系统的边界在哪里谁提供数据给系统系统又把结果给谁。画上下文图的关键动作是定边界。边界定得宽系统里就塞进一堆不属于你的处理边界定得窄关键数据流又露在外面。我常用的办法是问三个问题没有这个角色数据就进不来的是谁处理完的数据最终要交给谁有哪些外部组织或系统会主动跟我们的系统交换数据上下文图画完之后整张图里所有数据流都必须从外部实体出发或到达外部实体中间不能有任何中断。如果发现有外部实体之间直接连了数据流说明边界画错了或者你画成了业务流程图。2.2 0层图把系统炸成几大块0层图就是把上下文图里那个整个系统的黑盒打开拆成几个主要加工。每个加工对应一个大的业务功能区。拆分的依据是什么我的经验是找动词。把系统能做的大事全部列出来比如处理订单管理库存生成报表维护用户信息每个大字都是一个候选加工。然后再看看这些加工之间需要传递哪些数据把它们连接起来数据存储也在这一层开始出现。0层图要遵守一条铁律跟上下文图保持平衡。也就是说0层图整体的输入输出数据流必须和上下文图的输入输出数据流完全一致。这里说的完全一致是指数据流的名字和方向都对得上可以合并成一条总流但不能多也不能少。比如上下文图里系统接收借书请求0层图里就必须至少有一条数据流最终承载借书请求进入某个加工。2.3 继续分解子图平衡是底线0层图里的每个加工如果内部逻辑还复杂就继续往下分解得到1层图、2层图……这个过程就是上下文数据流图的分解也是网上经常搜到的上下文数据流图分解做法的核心。分解时同样要平衡父图里某个加工的所有输入输出数据流在子图里必须原样出现。比如父图里处理借书这个加工输入是借书请求和读者信息输出是借阅记录和借书结果那子图里这些数据流必须都存在不能凭感觉删掉或改名。什么时候停止分解标准很简单加工对应到具体某个程序模块或某个算法的内部步骤时就没必要再画了。我自己定的界限是一个加工如果内部不超过三个动作就停下。画得太细会陷入实现细节数据流图就退化成流程图了。3. 手把手画一遍图书管理系统的数据流图理论讲一堆不如上手画一张。我拿图书管理系统当例子把每个步骤拆开讲看完你就能照着画出自己的系统。3.1 先找外部实体定清楚系统边界图书管理系统先想外部实体。最明显的是读者他要借书、还书、查书。其次是图书管理员他要上架新书、下架旧书、处理借还操作。如果还要对接外部图书馆联盟做馆际互借那就再加一个实体的外部系统。这里我要提醒一句外部实体一定是人或者系统绝对不要画成数据库文件系统。数据库是存储属于系统内部。有次评审看到有人把数据库画成外部实体说明他把物理实现和逻辑结构搞混了——数据流图不关心数据存在MySQL还是Oracle只关心逻辑上有哪些数据存储。然后是系统边界。图书管理系统的边界就是所有跟图书借还相关的业务操作。查询图书目录算系统内打印财务报表如果不在系统需求里就算系统外。3.2 拆加工把业务动作画成圆角矩形上下文图确定后把系统打开画0层图。图书管理系统可以拆成四个加工图书管理、读者管理、借还管理、查询统计。这四个加工覆盖了系统的主要业务行为。然后再往下拆。比如借还管理这个加工继续拆成处理借书处理还书处理续借三个子加工。到这一步加工已经对应到具体的功能模块可以停了。拆加工的时候最容易犯的错是动作碎片化。比如处理借书里不要再拆出验证读者更新库存登记记录这种细动作除非你要继续画到1层图。如果你发现一个加工里有明显的先后顺序和条件判断说明你已经在画流程图的边缘了赶紧收住。3.3 数据存储和数据流命名的讲究图书管理系统的数据存储有图书表、读者表、借阅记录表。存储的命名一定要是名词而且最好是业务术语而不是数据库表名。如果图书表在数据库里叫t_book数据流图里还是要写图书基本信息不然业务人员看不懂。数据流的名字比存储还讲究。数据流上必须写名字吗必须写。一条没有名字的数据流等于没说。名字用名词要能准确表达流经这条线的那份数据。别用数据信息东西这种万能词那是画了等于没画。我见过最典型的错误是数据流名写成动词或动宾短语比如发送订单验证用户。数据流是正在流动的数据本身叫订单信息用户凭证才对。动词该出现在加工的名字里。3.4 编号规则一秒钟定位你在哪一层规范的编号是数据流图专业度的分水岭。上下文图可以不编号0层图开始每个加工按1、2、3编号1层图里的加工编号采用小数点制比如加工1的子加工是1.1、1.2、1.3再往下就是1.1.1、1.1.2。这套编号的隐藏价值是能快速导航。开发看一张画满十来个加工的大图只要看到某个加工叫3.2就知道它是0层图加工3的子功能。我们团队内部审查时也按编号对图哪个加工缺了输入输出一查编号马上能定位到是哪一层的平衡没守好。我还会给数据存储也做编号D1、D2、D3。这样在子图里写读取D2比写读取读者信息表更简洁配合图例也不会产生歧义。4. 查询和修改场景数据流图最容易被画歪的地方网上查数据流图资料时查询修改是高频词因为这类场景在考试、面试和实际系统里都是标配。但偏偏是这种看起来简单的场景错误率最高。我逐一说清楚。4.1 查询类加工数据从哪来到哪去查询动作的本质是从存储里取数据加工后返回给外部实体。以按书名查询图书为例正确的画法是外部实体读者发出数据流查询条件书名的关键词数据流进入加工查询图书信息加工从存储D1图书基本信息读取匹配的数据加工输出数据流图书查询结果给外部实体读者。关键点有三个一是查询条件是一股独立的数据流别跟查询结果共用一条线更不能用来回双箭头。数据流图里箭头就是单向数据不会在一个时间段内同时双向流动。二是查询操作并没有改变存储里的内容所以从D1到加工的方向是读就是存储指向加工如果查询后还要更新某个最近查询记录那才需要加工往存储写数据。三是查询结果只要是从存储取出来的即使没有经过任何计算也要画加工节点。有人嫌麻烦直接画实体→存储→实体这是错的因为外部实体不能直接访问数据存储。4.2 修改类加工三步走不能省修改数据的本质是把外部传入的新信息覆盖到存储的旧信息上它必须经过加工而且通常需要先查询再做修改。以图书管理员修改读者联系方式为例外部实体图书管理员发出数据流读者修改信息含读者ID、新手机号加工修改读者信息先把相关读者原信息从D2读者信息表读出来这一步是为了校验读者是否存在、决定更新还是插入加工把新信息写入D2加工输出数据流修改结果给图书管理员。所以修改类加工至少有三条数据流一条输入是修改内容一条是往存储写入的数据流一条是修改结果反馈。很多人漏掉读取原信息这一步直接把新信息写入存储导致修改逻辑里老数据校验完全丢失。还有一个易错点是修改与查询合并的问题。有人说修改数据流图就是先查出来再改所以画一个加工就够了。我的建议是如果查询和修改在业务上是两个独立入口就分开画两个加工如果是同一个表单里先查出来再编辑保存按两个加工串起来画。别硬把它们合并成一个查询修改加工那会掩盖真实业务流程后面做接口设计时很难拆分。4.3 查询修改合图时的常见混乱当查询和修改出现在同一张图上时最常见的混乱是数据流方向写反。我评审时经常看到读者信息从存储指向实体意思是把这个数据流当成了修改后的输出——但是如果“修改结果”只是成功失败提示那“读者信息”这条流就得进加工再出来而不是直接从存储飞到实体。另一个混乱是存储的读写不分。一条数据流如果既代表读又代表写说明画图人没想清楚。我的处理办法是先在草稿纸上把每个加工涉及的数据流全部列出来标注读D几写D几再连线。这样能避免边画边想导致的箭头方向错误尤其是有多个加工同时读写同一存储时。还有命名问题。查询和修改共用同名数据流时比如读者信息必须区分成读者查询条件读者查询结果读者修改信息读者最新信息。一份数据在修改前后内容不同名字却不能让它混淆。数据流命名里带着动作场景后面做接口字段对接时能省去大量沟通。5. 常见错误、自检清单和工具选择图纸画完不代表工作结束数据流图的错误如果不流到评审阶段后面就是灾难。我把这些年见到的错误整理成速查再给你一份自检清单和工具参考。5.1 五个常见坑个个都踩过第一个坑把控制流当数据流。比如点击按钮超时触发发送提醒这类描述本质是控制动作或事件不是数据本身。数据流图里不应该有这些。有次系统设计里有人画了用户点击查询的数据流整个评审笑场但笑完大家都意识到很多人就是分不清。第二个坑加工只有输入没有输出或者只有输出没有输入。前者叫黑洞数据进去了出不来后者叫白洞凭空变出数据。出现这种情况基本说明加工逻辑没想全。比如打印报表加工只有报表打印请求输入却没有报表数据流输出。第三个坑数据存储没有数据流经过。画了一个存储却没有加工读它或写它那它出现在图里毫无意义。反过来如果存储被某个加工读写但流上没写名字等于没画。第四个坑父子图不平衡。0层图输入输出和上下文图对不上子图输入输出和父图对不上。这是分层画法里最打击人的错误而且越大越难排查。我建议每画完一层立刻停下来拿着父图逐条核对数据流名字和方向别攒到最后一起查。第五个坑为了美观牺牲语义。数据流图不是架构图不要把实体和加工摆得过于分散也不要为了减少交叉线而硬把两个没有数据关系的节点连起来。图乱一点没事业务错才是大事。5.2 画完之后的15分钟自检每次画完一张数据流图我会强制走一遍自检流程大概花15分钟但能省下后面评审一天的扯皮。第一步逐条数据流验证每条流上都有名词性名字都有明确的源和终点且源和终点至少一方是加工。第二步逐加工验证每个加工都有动词性名字至少一条输入流和一条输出流。第三步逐存储验证每个存储都被至少一个加工读取或写入存储之间没有直接数据流外部实体不直接连存储。第四步平衡检查当前图层所有数据流与父图层一一对应名字和方向完全一致。第五步无控制流检查图上没有按钮点击判断循环这类控制逻辑。第六步让一个不了解系统的人看图能说出这个系统大概做什么、数据从哪来、到哪去。第六步最难也最有效。我经常发现自己觉得理所当然的业务术语别人看了完全不知道什么意思。数据流图的价值在于沟通能用大白话让外行看懂才是真的画好了。5.3 工具推荐手绘、draw.io还是Visio工具选择因人而异我按场景给你参考。白板或纸笔是传家宝。需求讨论早期几个人围在白板前画上下文图和0层图效率远超任何软件。数据流图的核心是快速迭代和讨论白板上的图随时能擦掉重画这个优势不可替代。draw.io现在叫draw.io也可部署为diagrams.net是我日常主力。免费、浏览器打开就能用也能集成到很多文档平台。它内置DFD图形模板画完能导出PNG和SVG。缺点是样式偏工程化不喜欢默认美化效果的话需要自己调。ProcessOn国内用着顺手模板多在线协作好。适合需要频繁跟同事远程同步画图的场景缺点是非会员能创建的图数量有限。Visio是老牌重型工具适合交付给客户的企业级文档图形规范、打印效果好。缺点是价格不低且打开稍微有点重。如果只是自己画个草图完全没必要上Visio。我个人的习惯是头脑风暴用白板正式文档用draw.io画涉及复杂交付再统一转成Visio格式。工具不重要重要的是图里承载的逻辑清晰、命名规范、分层正确。6. 数据流图画完之后的落地思路一张数据流图画完后面能承接的工作其实不少这里顺便说说我的落地经验。它能直接帮助划分系统模块。0层图里的每个加工基本就是一个高内聚的功能模块1层图里的子加工对应到模块内部的具体函数或类。做接口设计时两个加工之间的数据流很快就变成API的输入输出参数。它还能校验需求完整性。你对着数据流图检查需求文档发现外部实体或加工没有对应需求的描述说明需求有遗漏反过来发现需求里的功能在图里没有对应的加工说明需求超出边界或你漏画了。我每次做需求评审前都会强制更新一版数据流图带着图去开会效率比干讲需求文档高得多。像查询修改这类场景如果在数据流图阶段就明确了数据流方向、读写存储的细节数据库事务边界、缓存策略、接口设计基本都能顺出来。很多人设计系统时总觉得缺一张总览图其实要的那张就是一张合格的数据流图。画好这一张后面开发和测试能少走很多弯路。 
长河君 · 2026/10/2 1:30:48 · 阅读 1.2k 数据流图画法全解析：从上下文图到分层与常见误区
画数据流图这件事我刚开始入行那几年是真没当回事觉得不就是几个框框加箭头嘛。直到有一次接手一个老系统做功能迁移折腾了整整一周理不清业务边界最后是老同事丢过来一张泛黄的数据流图十分钟我就知道数据从哪进来、经过哪些处理、存到哪去。从那以后我自己画任何系统设计图第一张永远先画数据流图。这东西看起来简单但真能画得规范和有用的比想象中少得多。这篇就围绕数据流图的画法把上下文图、分层分解、加工与存储的细节、查询修改这类典型场景以及我自己踩过的坑一次性讲透。适合正在学软件工程的学生、刚转行做需求的同学以及明明画了图但总被开发吐槽看不懂的产品和测试。1. 数据流图是啥四个要素和它解决的核心问题数据流图Data Flow Diagram简称DFD描述的是数据在系统里怎么流动、怎么被加工、存在哪里它完全不关心谁在操作、什么时候操作。你可以把它理解成一张数据物流地图货物就是数据仓库就是数据存储加工车间就是处理逻辑发货方和收货方就是外部实体。1.1 四个基本要素比你想的简单数据流图一共就四样东西别被各种教材里花里胡哨的符号吓到。外部实体在系统外面但跟系统有数据往来的角色比如用户、银行、供应商。一般用矩形框表示可以画阴影区分。外部实体是系统的边界数据从它这里进入系统处理完再回到它手里。加工Process对数据做的事比如验证账号计算运费生成订单。用圆角矩形或圆形表示必须有一个动词开头的名字必须能说出它做了什么操作。数据存储Data Store数据待着的地方数据库表、文件、缓存都算。用两条平行线开口矩形表示名字用名词比如订单表用户缓存。数据流Data Flow一条带箭头的线代表一份数据从一处到另一处。名字必须是个名词比如订单信息查询条件箭头方向就是数据流动方向。这四样放在一起就能完整回答三个问题系统跟谁打交道实体、系统做什么加工、做的时候数据怎么进怎么出数据流和存储。我在实际画图时最深的体会是这四个要素的命名一旦规范整张图的信息量立刻翻倍。1.2 数据流图和流程图、ER图有什么区别很多新手把数据流图画成了流程图这是最大的误区。流程图描述的是做什么事情、按什么顺序做强调的是控制逻辑和步骤顺序里面的箭头是流转带着时间先后。数据流图的箭头是数据本身在流动不包含任何顺序含义甚至不应该出现如果否则循环这类控制逻辑。ER图描述的是数据之间有什么关系强调的是静态结构。数据流图描述的是数据怎么在路上走强调的是动态行为。这三者的关系我一般这样跟团队解释先有数据流图理清业务脉络再从数据流图里提炼出需要存储的数据结构画ER图最后才针对每个加工画流程图实现。顺序反了基本都会返工。我自己就吃过亏有次先画了精密的ER图结果发现业务流程根本走不通又回头重画数据流图才找到问题——数据表设计得再好也得先让数据按业务流起来。2. 画图之前必须先搞懂的分层套路数据流图最核心的画法不是在一个图层里把所有东西画出来而是分层——这也是很多教材强调的自顶向下逐层分解。为什么非要分层因为真实业务系统不可能一张图画完硬画的结果就是线条交叉、信息爆炸谁看了都头大。分层的思路跟看地图一模一样先看整个城市再看各区最后放大到街道。数据流图通常分三层就够了。2.1 上下文图一张图装下整个系统上下文图也叫顶层图是整套数据流图的第0层。这一层只有一个加工代表整个系统把系统看成一个黑盒只画外部实体和系统之间的数据流。它回答的问题是系统的边界在哪里谁提供数据给系统系统又把结果给谁。画上下文图的关键动作是定边界。边界定得宽系统里就塞进一堆不属于你的处理边界定得窄关键数据流又露在外面。我常用的办法是问三个问题没有这个角色数据就进不来的是谁处理完的数据最终要交给谁有哪些外部组织或系统会主动跟我们的系统交换数据上下文图画完之后整张图里所有数据流都必须从外部实体出发或到达外部实体中间不能有任何中断。如果发现有外部实体之间直接连了数据流说明边界画错了或者你画成了业务流程图。2.2 0层图把系统炸成几大块0层图就是把上下文图里那个整个系统的黑盒打开拆成几个主要加工。每个加工对应一个大的业务功能区。拆分的依据是什么我的经验是找动词。把系统能做的大事全部列出来比如处理订单管理库存生成报表维护用户信息每个大字都是一个候选加工。然后再看看这些加工之间需要传递哪些数据把它们连接起来数据存储也在这一层开始出现。0层图要遵守一条铁律跟上下文图保持平衡。也就是说0层图整体的输入输出数据流必须和上下文图的输入输出数据流完全一致。这里说的完全一致是指数据流的名字和方向都对得上可以合并成一条总流但不能多也不能少。比如上下文图里系统接收借书请求0层图里就必须至少有一条数据流最终承载借书请求进入某个加工。2.3 继续分解子图平衡是底线0层图里的每个加工如果内部逻辑还复杂就继续往下分解得到1层图、2层图……这个过程就是上下文数据流图的分解也是网上经常搜到的上下文数据流图分解做法的核心。分解时同样要平衡父图里某个加工的所有输入输出数据流在子图里必须原样出现。比如父图里处理借书这个加工输入是借书请求和读者信息输出是借阅记录和借书结果那子图里这些数据流必须都存在不能凭感觉删掉或改名。什么时候停止分解标准很简单加工对应到具体某个程序模块或某个算法的内部步骤时就没必要再画了。我自己定的界限是一个加工如果内部不超过三个动作就停下。画得太细会陷入实现细节数据流图就退化成流程图了。3. 手把手画一遍图书管理系统的数据流图理论讲一堆不如上手画一张。我拿图书管理系统当例子把每个步骤拆开讲看完你就能照着画出自己的系统。3.1 先找外部实体定清楚系统边界图书管理系统先想外部实体。最明显的是读者他要借书、还书、查书。其次是图书管理员他要上架新书、下架旧书、处理借还操作。如果还要对接外部图书馆联盟做馆际互借那就再加一个实体的外部系统。这里我要提醒一句外部实体一定是人或者系统绝对不要画成数据库文件系统。数据库是存储属于系统内部。有次评审看到有人把数据库画成外部实体说明他把物理实现和逻辑结构搞混了——数据流图不关心数据存在MySQL还是Oracle只关心逻辑上有哪些数据存储。然后是系统边界。图书管理系统的边界就是所有跟图书借还相关的业务操作。查询图书目录算系统内打印财务报表如果不在系统需求里就算系统外。3.2 拆加工把业务动作画成圆角矩形上下文图确定后把系统打开画0层图。图书管理系统可以拆成四个加工图书管理、读者管理、借还管理、查询统计。这四个加工覆盖了系统的主要业务行为。然后再往下拆。比如借还管理这个加工继续拆成处理借书处理还书处理续借三个子加工。到这一步加工已经对应到具体的功能模块可以停了。拆加工的时候最容易犯的错是动作碎片化。比如处理借书里不要再拆出验证读者更新库存登记记录这种细动作除非你要继续画到1层图。如果你发现一个加工里有明显的先后顺序和条件判断说明你已经在画流程图的边缘了赶紧收住。3.3 数据存储和数据流命名的讲究图书管理系统的数据存储有图书表、读者表、借阅记录表。存储的命名一定要是名词而且最好是业务术语而不是数据库表名。如果图书表在数据库里叫t_book数据流图里还是要写图书基本信息不然业务人员看不懂。数据流的名字比存储还讲究。数据流上必须写名字吗必须写。一条没有名字的数据流等于没说。名字用名词要能准确表达流经这条线的那份数据。别用数据信息东西这种万能词那是画了等于没画。我见过最典型的错误是数据流名写成动词或动宾短语比如发送订单验证用户。数据流是正在流动的数据本身叫订单信息用户凭证才对。动词该出现在加工的名字里。3.4 编号规则一秒钟定位你在哪一层规范的编号是数据流图专业度的分水岭。上下文图可以不编号0层图开始每个加工按1、2、3编号1层图里的加工编号采用小数点制比如加工1的子加工是1.1、1.2、1.3再往下就是1.1.1、1.1.2。这套编号的隐藏价值是能快速导航。开发看一张画满十来个加工的大图只要看到某个加工叫3.2就知道它是0层图加工3的子功能。我们团队内部审查时也按编号对图哪个加工缺了输入输出一查编号马上能定位到是哪一层的平衡没守好。我还会给数据存储也做编号D1、D2、D3。这样在子图里写读取D2比写读取读者信息表更简洁配合图例也不会产生歧义。4. 查询和修改场景数据流图最容易被画歪的地方网上查数据流图资料时查询修改是高频词因为这类场景在考试、面试和实际系统里都是标配。但偏偏是这种看起来简单的场景错误率最高。我逐一说清楚。4.1 查询类加工数据从哪来到哪去查询动作的本质是从存储里取数据加工后返回给外部实体。以按书名查询图书为例正确的画法是外部实体读者发出数据流查询条件书名的关键词数据流进入加工查询图书信息加工从存储D1图书基本信息读取匹配的数据加工输出数据流图书查询结果给外部实体读者。关键点有三个一是查询条件是一股独立的数据流别跟查询结果共用一条线更不能用来回双箭头。数据流图里箭头就是单向数据不会在一个时间段内同时双向流动。二是查询操作并没有改变存储里的内容所以从D1到加工的方向是读就是存储指向加工如果查询后还要更新某个最近查询记录那才需要加工往存储写数据。三是查询结果只要是从存储取出来的即使没有经过任何计算也要画加工节点。有人嫌麻烦直接画实体→存储→实体这是错的因为外部实体不能直接访问数据存储。4.2 修改类加工三步走不能省修改数据的本质是把外部传入的新信息覆盖到存储的旧信息上它必须经过加工而且通常需要先查询再做修改。以图书管理员修改读者联系方式为例外部实体图书管理员发出数据流读者修改信息含读者ID、新手机号加工修改读者信息先把相关读者原信息从D2读者信息表读出来这一步是为了校验读者是否存在、决定更新还是插入加工把新信息写入D2加工输出数据流修改结果给图书管理员。所以修改类加工至少有三条数据流一条输入是修改内容一条是往存储写入的数据流一条是修改结果反馈。很多人漏掉读取原信息这一步直接把新信息写入存储导致修改逻辑里老数据校验完全丢失。还有一个易错点是修改与查询合并的问题。有人说修改数据流图就是先查出来再改所以画一个加工就够了。我的建议是如果查询和修改在业务上是两个独立入口就分开画两个加工如果是同一个表单里先查出来再编辑保存按两个加工串起来画。别硬把它们合并成一个查询修改加工那会掩盖真实业务流程后面做接口设计时很难拆分。4.3 查询修改合图时的常见混乱当查询和修改出现在同一张图上时最常见的混乱是数据流方向写反。我评审时经常看到读者信息从存储指向实体意思是把这个数据流当成了修改后的输出——但是如果“修改结果”只是成功失败提示那“读者信息”这条流就得进加工再出来而不是直接从存储飞到实体。另一个混乱是存储的读写不分。一条数据流如果既代表读又代表写说明画图人没想清楚。我的处理办法是先在草稿纸上把每个加工涉及的数据流全部列出来标注读D几写D几再连线。这样能避免边画边想导致的箭头方向错误尤其是有多个加工同时读写同一存储时。还有命名问题。查询和修改共用同名数据流时比如读者信息必须区分成读者查询条件读者查询结果读者修改信息读者最新信息。一份数据在修改前后内容不同名字却不能让它混淆。数据流命名里带着动作场景后面做接口字段对接时能省去大量沟通。5. 常见错误、自检清单和工具选择图纸画完不代表工作结束数据流图的错误如果不流到评审阶段后面就是灾难。我把这些年见到的错误整理成速查再给你一份自检清单和工具参考。5.1 五个常见坑个个都踩过第一个坑把控制流当数据流。比如点击按钮超时触发发送提醒这类描述本质是控制动作或事件不是数据本身。数据流图里不应该有这些。有次系统设计里有人画了用户点击查询的数据流整个评审笑场但笑完大家都意识到很多人就是分不清。第二个坑加工只有输入没有输出或者只有输出没有输入。前者叫黑洞数据进去了出不来后者叫白洞凭空变出数据。出现这种情况基本说明加工逻辑没想全。比如打印报表加工只有报表打印请求输入却没有报表数据流输出。第三个坑数据存储没有数据流经过。画了一个存储却没有加工读它或写它那它出现在图里毫无意义。反过来如果存储被某个加工读写但流上没写名字等于没画。第四个坑父子图不平衡。0层图输入输出和上下文图对不上子图输入输出和父图对不上。这是分层画法里最打击人的错误而且越大越难排查。我建议每画完一层立刻停下来拿着父图逐条核对数据流名字和方向别攒到最后一起查。第五个坑为了美观牺牲语义。数据流图不是架构图不要把实体和加工摆得过于分散也不要为了减少交叉线而硬把两个没有数据关系的节点连起来。图乱一点没事业务错才是大事。5.2 画完之后的15分钟自检每次画完一张数据流图我会强制走一遍自检流程大概花15分钟但能省下后面评审一天的扯皮。第一步逐条数据流验证每条流上都有名词性名字都有明确的源和终点且源和终点至少一方是加工。第二步逐加工验证每个加工都有动词性名字至少一条输入流和一条输出流。第三步逐存储验证每个存储都被至少一个加工读取或写入存储之间没有直接数据流外部实体不直接连存储。第四步平衡检查当前图层所有数据流与父图层一一对应名字和方向完全一致。第五步无控制流检查图上没有按钮点击判断循环这类控制逻辑。第六步让一个不了解系统的人看图能说出这个系统大概做什么、数据从哪来、到哪去。第六步最难也最有效。我经常发现自己觉得理所当然的业务术语别人看了完全不知道什么意思。数据流图的价值在于沟通能用大白话让外行看懂才是真的画好了。5.3 工具推荐手绘、draw.io还是Visio工具选择因人而异我按场景给你参考。白板或纸笔是传家宝。需求讨论早期几个人围在白板前画上下文图和0层图效率远超任何软件。数据流图的核心是快速迭代和讨论白板上的图随时能擦掉重画这个优势不可替代。draw.io现在叫draw.io也可部署为diagrams.net是我日常主力。免费、浏览器打开就能用也能集成到很多文档平台。它内置DFD图形模板画完能导出PNG和SVG。缺点是样式偏工程化不喜欢默认美化效果的话需要自己调。ProcessOn国内用着顺手模板多在线协作好。适合需要频繁跟同事远程同步画图的场景缺点是非会员能创建的图数量有限。Visio是老牌重型工具适合交付给客户的企业级文档图形规范、打印效果好。缺点是价格不低且打开稍微有点重。如果只是自己画个草图完全没必要上Visio。我个人的习惯是头脑风暴用白板正式文档用draw.io画涉及复杂交付再统一转成Visio格式。工具不重要重要的是图里承载的逻辑清晰、命名规范、分层正确。6. 数据流图画完之后的落地思路一张数据流图画完后面能承接的工作其实不少这里顺便说说我的落地经验。它能直接帮助划分系统模块。0层图里的每个加工基本就是一个高内聚的功能模块1层图里的子加工对应到模块内部的具体函数或类。做接口设计时两个加工之间的数据流很快就变成API的输入输出参数。它还能校验需求完整性。你对着数据流图检查需求文档发现外部实体或加工没有对应需求的描述说明需求有遗漏反过来发现需求里的功能在图里没有对应的加工说明需求超出边界或你漏画了。我每次做需求评审前都会强制更新一版数据流图带着图去开会效率比干讲需求文档高得多。像查询修改这类场景如果在数据流图阶段就明确了数据流方向、读写存储的细节数据库事务边界、缓存策略、接口设计基本都能顺出来。很多人设计系统时总觉得缺一张总览图其实要的那张就是一张合格的数据流图。画好这一张后面开发和测试能少走很多弯路。