DFD分层建模实战：从上下文图到子图平衡全解析

做系统需求分析这些年，我最常见的现场不是业务讲不清楚，而是讲着讲着，需求方、产品、开发各自手里已经有三张完全对不上的流程草图。一张图画了十多个处理，另一张只画了“下单、支付、发货”三个大框，谁也说服不了谁。后来我才意识到，问题不是大家不认真，而是不知道数据流图（DFD）这张工具图，天生就需要配合“分层建模”来用，不能指望一张图搞定所有粒度的表达。

结构化分析方法里反复强调的数据流图分层建模，核心思想其实很简单：先有一张只画系统边界和外部实体的顶层上下文图，再把系统这个大加工拆成几个一级加工，某个一级加工如果还复杂，就继续拆成二级子图。这样从上到下，每张图的信息量都保持可控，每一层之间又能互相验证。听上去像是个老生常谈的画图纪律，但实操中，真正能把上下文图拆得干净、父图子图配平、还能避开黑洞奇迹灰洞的人并不多。这篇文章就从原理到案例，把 DFD 分层建模这条路完整走一遍。

1. 分层不是把图画小，是把边界画清楚

1.1 单张DFD为什么必然走向失控

DFD 最擅长的事情，是表达“数据从哪来、经过什么加工、写到哪里、又交给谁”。如果你面对的只是一个几百行代码量的小功能，一张 DFD 完全够用。但哪怕业务规模只是中型，比如一个订单系统同时涉及外部客户、财务平台、仓库系统、售后客服，单张图就会立刻失控。

我见过有人硬把系统的所有处理画在一页纸上，结果图上三十多个圆圈、二十多条数据流挤在一起。那张图最要命的地方在于：你只要想确认“客户提交订单”这条路径最终影响了哪些数据存储，视线就不得不在几条看似无关的箭头之间来回跳。再想画得细一点，图面直接变成蜘蛛网。更现实的问题是，这种单层大图根本没法评审，因为业务方和开发关心的粒度不同：业务方只想看系统整体和外部系统的接口关系，开发想看到某个处理内部到底读了哪几张表。

所以结构化分析引入分层建模，本质上不是把一张图画小，而是让不同的人可以在不同粒度上只看自己关心的那层图。越靠近系统边界，图越粗；越往下展开，图越细。每一层只负责回答一个粒度的问题。

1.2 三个典型层级各自要承担什么责任

习惯上，DFD 分层模型会从上下文图开始。上下文图也叫顶层图，整张图只出现一个加工，这个加工就是你要分析的那套系统。外部实体通过数据流和这个加工相连，但图上不会画任何内部存储和内部处理，因为你在这层要确认的是：系统的边界在哪，外界谁会给系统提供数据，系统又要把数据送给谁。

再往下是 Level 0 主干图，也就是把上下文图那个大加工展开成若干一级加工，并补充需要持久化的数据存储。这层图通常用于业务域的内部职责划分。一个订单系统的 Level 0，大概率会区分成订单受理、库存处理、支付结算、消息通知等几个一级加工。外部实体仍然要保留，因为数据流最终要落到真实的人和系统上。

如果 Level 0 的某个加工还是很复杂，比如“支付结算”内部还涉及回调、退款、对账多个环节，就为它单独画一张 Level 1 子图，把一级加工继续拆成二级加工。这个过程可以继续往下，一直拆到每个加工都能被一个人或者一个开发任务清晰承接为止。

1.3 一张表看懂DFD分层的层级关系

为了便于后续讨论，我用下面的表把常见层级对应起来。不同企业、不同教材对“第几层”的编号习惯略有差异，有的把上下文图叫第0层，有的叫第1层，这本身不重要，重要的是团队文档里统一。

记住一个核心原则：每张子图本质上都是父图里某一个加工的“放大镜”。你把放大镜盖上去以后，看到的内部细节可以有很多，但从放大镜边缘穿过的数据流，必须和父图中该加工上的数据流保持一致。这就是后面要重点讲的父图子图平衡。

2. 先记牢这组词汇，画起图才不会自相矛盾

2.1 DFD的四个基本构成元素

做 DFD 分层建模之前，必须先把四个元素刻在脑子里。

第一个是外部实体，也叫源点或终点，代表系统外界的人或系统，比如客户、仓储系统、短信平台。它的作用是帮你定义边界：凡是只从外界给数据、或只接收系统数据、不参与内部处理的，都应该画成外部实体。

第二个是加工，也叫处理，它是 DFD 的核心。每个加工代表一次数据变换，比如“校验订单”“计算金额”“更新库存”。加工必须有编号，编号同时承担着它在本层的位置信息。

第三个是数据存储，它表示静止等待被读取和写入的数据。注意，在 DFD 里数据存储是一个逻辑概念，不等同于某张具体的数据库表，更不等同于文件系统路径。它可以是一个账单文件、一个缓存队列、一张订单表。

第四个是数据流，它是连接前面三个元素的箭头。数据流必须命名，并且命名要尽量准确反映它所承载的数据内容，不能只叫“数据”“信息”这种空泛词。

外部实体之间不能直接画数据流，数据存储之间也不能直接画数据流。数据流要想穿过系统内部，一定要经过至少一个加工，否则就说明你还漏画了关键的处理动作。

2.2 两种建模符号门派怎么选

DFD 有两大常见符号体系，很多新手第一次接触时都会被两套画法搞混。沿用得比较广的是 Yourdon/DeMarco，加工用圆圈表示，数据存储用两条平行线表示。另一套 Gane/Sarson 则把加工画成圆角矩形，数据存储用一侧开口的矩形表示。

我在实际项目里其实不太挑门派，因为大部分团队画图用的工具本身就能切换。真正重要的是自始自终只用一套，不允许一套图里今天用圆圈加工、明天用圆角矩形加工。混合使用会给评审带来无谓噪音，尤其在分层图数量很多的时候，符号不统一会直接导致低层子图被误读。

还有一点容易忽略：不要把 DFD 符号和业务流程图符号揉在一起。有些同学画 DFD 时，为了表达“如果金额大于多少就进入人工审核”，会在数据流边上加一个菱形判断框。这在 DFD 里是严重违规的。DFD 只表达数据的加工与流转，不表达触发条件、时间顺序和分支规则，那些东西应该交给流程图或状态图去表达。

2.3 数据流命名是分层能否验证的生命线

命名这件事，越早较真，后期越省力。我评审过的图里，大量黑洞奇迹和父子不平衡问题都出在命名随意上。

对于数据流上的命名，建议采用名词短语，比如“客户订单”“支付回执”“库存扣减通知”。命名要能表达“这一组数据的业务含义”，而不是表达动作。反过来，加工命名应该采用动词短语，比如“校验订单”“生成发货单”“登记退换货”。如果你在加工上写的是“订单处理”这种纯名词，读者会很难判断这个加工到底在做什么变换。

一旦开始分层，流的名字就变成了跨层对账的关键锚点。父图中叫“有效订单”，子图中却拆成了“订单头信息”和“订单商品明细”，如果没有在数据字典里写明父子组成关系，评审时几乎必然会被判定不平衡。所以在图例之外，数据字典不是一个可选项，而是分层 DFD 的另一条腿。

2.4 与流程图的界限必须守住

不画控制流、不画分支判断、不画异常顺序，是我给所有刚开始画 DFD 的人定下的三条禁令。DFD 是一种数据视角的模型，它回答的是“有哪些数据参与、被谁加工、最终流向哪”，并不回答“第一步做什么、第二步做什么”。数据流图上也尽量不表达“先做 A 再做 B”的时序，因为一旦加入顺序偏好，就会把图的复用性锁死。

你在评审时可能收到业务方这样的反馈：“我们还有一条流程是订单取消后先要通知客户，然后再通知仓库。”这句话听起来像是一个数据处理动作，实际上往往涉及多个时序分支。正常的做法是先在用例里把业务事件梳理清楚，再在 DFD 中用多个加工表达数据流转，而不必把 if else 画到图上。守住这一条，你的每张图才可能保持足够的抽象能力。

2.5 最关键的规则：父子平衡

父子平衡是分层 DFD 的灵魂。所谓平衡，说的是当你把父图中的一个加工展开成一张子图时，把整张子图重新看成一个大加工，这个“大加工”对外连接的数据流，必须和父图里那个被展开加工对外连接的数据流完全一致。

这句话翻译成大白话就是：放大镜盖上去以后，边缘进出的箭头不能变多，也不能变少，更不能改名字改到对不上号。你可以在子图内部尽情展示处理步骤和数据存储，但只要数据流跨出子图边界，就必须原封不动地和父图对应的加工对上。

这里还要特别提醒：如果子图内部出现了一个全新的外部实体，而上下文图和 Level 0 里根本没有它，这通常不是“子图画得更细”，而是说明你的上下文图画漏了。正确做法是回头把上层边界也同步修正，而不是放任高低层不一致。父子平衡不只是检查项，它其实是贯穿整套 DFD 的自我纠错机制。

3. 从上下文图往下拆，一套可以照做的流程

3.1 第一步：确定外部实体，先不急着画内部加工

我习惯在拿到一份需求文档后，先圈外部实体。外部实体通常是一句话里出现过的人和系统：客户提交订单、仓储系统反馈出库、财务平台发起对账、短信网关发出通知。把这些人或系统列全，比直接去拆内部流程重要得多。

一个可用的小技巧是：把所有外部实体写到一张便笺上，然后问自己一句，“如果把这些外部实体全部从系统拿走，系统还剩下什么？”如果剩下的逻辑不完整，说明你还没理解系统职责；如果剩下的逻辑仍然很完整，那说明某些外部实体可能根本不应该出现在边界外，它或许应该是系统内的一个处理。

确定外部实体后，在图上把系统画成一个中央加工，再画出外部实体和它之间的数据流。这张上下文图，是全项目最值得花时间的那一张图，因为它定义了项目范围的合同。后期如果新的外部系统要接入，第一件事就是改这张图。

3.2 第二步：上下文数据流图的分解最容易踩坑

上下文数据流图的分解，就是把上下文图那一个中央加工拆成 Level 0 的多个一级加工。很多人会在这时候犯一个经典错：只顾着把需求里的功能列成加工，结果画的 Level 0 图等于一张“功能清单”，完全没有回答数据怎么流动。

以订单系统为例。上下文图里，外部实体会画成客户、仓储系统、财务系统。客户提交订单给系统，系统处理后要回报状态给客户，系统中还要向仓储系统下发发货指令，也要跟财务系统做支付请求和回执确认。当这个大加工被展开时，你需要在 Level 0 中体现数据的实际去向。

我当时一般会先列出 Level 0 的候选加工清单，再为每个加工找一条或几条贯穿它的数据链路，最后做一次连接检查。某个候选加工如果只有输入没有输出，或者只有一个孤零零的输出数据流而没有任何输入，说明它不是流程自然切分出来的加工，而是被功能列表强行拼凑出来的。

3.3 第三步：把一级加工继续拆分到“看得懂”为止

Level 0 画完之后，你会面对很多编号为 1、2、3 的加工。接下来不要着急全拆，而是先给每个加工标一个复杂度：是那种只有一条输入流、一条输出流的简单加工，还是内部明显含有若干个阶段的大加工。只有后者才需要进入 Level 1。

拿订单处理系统里的“库存与发货”这个一级加工举例。如果从 Level 0 看，它负责接收有效订单、读取库存、生成发货指令、接收出库回执并更新库存，这时我们看不出内部具体如何运转。给这张加工单独画一张 Level 1 子图，可以把内部加工编号为 2.1 生成拣货任务、2.2 分配承运商、2.3 生成发货单，并画出它们之间以及它们与库存台账之间的关系。

在拆子图的过程里，必须时刻对照父图。父图中的“库存与发货”加工接收外部数据流“有效订单”，子图边界上就必须同样接收一个叫“有效订单”的流；“库存与发货”要向仓储系统发出“发货指令”，子图边界上的最终出口也必须包含“发货指令”。如果为了内部方便，把“发货指令”改名成“配送任务单”，你需要在数据字典里给出等价定义，同时做好被评审人挑战的准备。

3.4 第四步：编号与数据字典一起维护

大型分层模型里，加工编号就是图的寻址系统。一级加工编号为 1、2、3，由 1 展开的子图里加工编号为 1.1、1.2，如果 1.2 继续展开，下一层就是 1.2.1。这套规则看起来简单，但实际维护时经常出状况。

最常见的问题是编号跳变，比如 1 号加工的子图里只画了 1.1 和 1.3，没有 1.2。这要么是拆图画漏了，要么是 1.2 被误删了，评审时必须重点追问。我通常会建议团队把编号当作“目录路径”来对待，所有子图文件名也用路径表示，例如 2-库存与发货-子图.md，这样当一张图迭代时，不会因为文件名和编号不一致导致文档失联。

数据字典的维护节奏和画图同步推进。每条数据流是什么组成、有哪些关键数据项、取值范围大概是什么，并不需要一次性全部写完，但每个流至少要在字典里能查到一句解释。等检查灰洞的时候，你才会发现数据字典不及时写的代价有多高。

3.5 第五步：拆到什么程度该停手

这个问题几乎是每次培训都会被问到的。DFD 分层拆到多深，没有一个绝对值，但我有一个比较接地气的判定标准：当某个叶子加工已经能准确对应到一个人在一个业务事件中能完成的动作，或者一个开发人员能独立实现的功能接口时，就不要再往下拆了。

过度拆分会让模型失去抽象价值。我见过有人把“计算订单金额”拆成“读取商品单价”“读取折扣比例”“相乘”“累加”四个加工，这种粒度已经不是系统分析，而是把代码逻辑搬到了图上。DFD 是要帮助业务和开发对齐语言，而不是变成一份伪代码。

从团队维护成本看，一般拆到 Level 2 就够大多数项目使用。能在一张图里讲清楚的加工，就不必再造一层子图。多余的层次只会放大父子不平衡的出错面积，让每一轮需求变更都要改动更多页面的图。

4. 黑洞、奇迹与灰洞：在设计阶段就能提前暴露的三种病灶

4.1 三种“数据洞”直接看图就能发现

在 DFD 评审中，业务老手常会用几个很形象的词来形容图中的问题：黑洞、奇迹和灰洞，也有的教材把奇迹叫作白洞。

黑洞指的是一个加工只有数据流进来，却没有数据流出去。这就好比信息进了一扇门就凭空消失了。出现黑洞，通常意味着某个输出的数据流漏画了，也可能是后续的加工还没有接上，导致数据链路断在这里。比如“校验订单”这个加工如果没有把校验结果送给后面的处理或存储，它在图上看就是一个黑洞。

奇迹或者说白洞，正好反过来，一个加工有输出，但没有任何输入数据流。这类加工在图面上像变魔术一样凭空产生数据。实践中，它往往代表你要么漏画了上游的数据流，要么这个加工依赖了某个外部传入参数，但你没有在图中体现。一个“生成对账文件”的加工如果没有任何输入，却向外输出一份对账结果，那这份结果从哪里来？不可能是从空气里长出来的。

灰洞比前两种更隐蔽，也很少有人第一次画图就能完全避开。它是指一个加工既有输入也有输出，但根据已有输入和可访问的数据存储，不足以推导出它的输出。通俗地说，这个加工有原料也有成品，但原料清单不完整。比如输出“最终结算金额”的加工，如果只接入了“商品原价”，却没有接入“优惠券金额”“运费规则”等输入，就会出现典型的灰洞。

4.2 灰洞不能只靠眼睛看，要借助数据字典查

初学 DFD 的人可能会觉得，只要每张图上的每个加工都至少有一条输入和一条输出，就不会有数据洞了。但灰洞恰恰说明这种检查还远远不够。

我通常会组织一次小型的“数据项核对会”。对每一个关键加工，列出它输出所需的数据项，再倒推这些数据项是否都出现在它的输入流或它可读的数据存储里。举例来说，加工“计算积分等级”输出“会员等级”，要计算等级至少需要“账号累计消费金额”和“等级规则”，两者缺一不可。如果图中只有“订单编号”流入该加工，而等级规则平时存放在某个数据存储里却没有画出读取流向，那么这个加工就成了灰洞。

这种核对会不需要把整张图的每一个数据项都逐字段检查一遍，否则工作量会大到无法执行。我通常聚焦在几个容易伪造结果的加工上，比如金额计算类、状态判断类、外部接口拼装类。这些加工一旦是灰洞，后续开发进入编码阶段时几乎一定会拿出产品方案来回讨论，提前卡掉能省掉很多重复沟通。

4.3 一个典型的父子图不平衡案例复盘

这里顺便把一个真实项目中很常见的父子图不平衡案例完整复盘一遍。某个父图里有一个编号为 1 的加工，叫“处理订单”，它接收的外部数据流是客户送来的“订单”和财务系统送来的“支付结果”，向外发出的数据流是发往客户的“状态通知”和发往仓储系统的“发货单”，同时会访问 D1 订单和 D2 库存两个存储。

现在把 1 号加工展开成 Level 1 子图。子图画了 1.1 接收订单、1.2 校验订单、1.3 更新订单状态、1.4 生成发货单。逐条对账时会发现：

这张子图只看内部逻辑，也许每个小加工都能各干各的事，但把它和父图放一起用“黑盒视角”检查，缺陷立即暴露。这正是我在评审子图时坚持用“把子图整体回装成父图加工”的方式去核对的原因。

4.4 快速定位数据洞的四个操作习惯

在实际评审时，我一般按四个动作来扫图：先数每个加工的进出箭头，数量明显异常的先用记号标出；再把子图的边界综合成一个“假想父加工”，和真正的父加工做输入输出对账；随后对穿过系统边界的关键流，从上下文图一路追到最底层叶子图，确保没有断链；最后打开数据字典，对计算类加工做输出项到输入项的覆盖检查。

这四个动作可以在一个小时内覆盖十到二十张图的规模。更理想的是，在评审会上让需求方一起参与，因为数据洞往往不是单纯的画图错误，它背后通常隐藏着一个还没有被讲清楚的业务规则。比如“空订单也允许生成支付链接”这种规则，如果需求文档没有写，图上也很难被发现。

4.5 DFD审核速查表

5. 越到后期越要较真，这些经验很实用

5.1 分层建模不是越细越好，要允许“不继续拆”

结构化分析方法经常给人留下一个印象：系统要拆到不能再拆才算完成。这在 DFD 分层建模里反而需要克制。如果一个叶子加工已经足够简洁，强行继续拆只会让图的数量膨胀，并让每层之间的平衡验证成本呈指数级上升。

有个比较现实的经验：一个分析模型里，需要拆到 Level 2 以上的加工通常不超过三分之一。大部分加工会在 Level 0 或 Level 1 停住。停住的判断标准不应该是“这个功能未来可能有变化，所以先拆细”，而应该是“当前这张图是否足以让各方理解并作出决策”。DFD 是为沟通服务的，不是为未来的想象服务的。

如果你真的觉得某个模块未来会很复杂，那也应该用一个新的用例去描述，而不是提前把所有未来分支都埋进今天的分层图里。过度设计不只发生在代码里，同样发生在数据流图里。

5.2 推荐工具和工作习惯，让分层图真正立起来

工具层面，我比较推荐那些支持“一图一页面、页面可跳转”的绘图工具，比如 draw.io、Visual Paradigm、ProcessOn 这类。可以用每张子图独立一页，然后在父图加工节点上挂子图链接，这样评审时从上下文图点击几次就能下钻到叶子图，效率比把所有图堆在一张大画布里高得多。

文件命名也是分层建模的隐形管理项。推荐用“编号-名称-层级”的规则，比如 L0-订单系统主干图、L1-1-订单处理子图。文件修改时保留旧版本，因为 DFD 分层最大的敌人不是一开始画错，而是改了三级图之后忘了同步父图。

我在实际项目中还养成了一个习惯：每张图的交付物不只是图本身，还要附一张“边界数据流清单”。就像代码要有接口定义一样，图也要把进出数据流做成清单，用表格列出流名、来源、去向、必要数据项。这个清单做出来后，低层子图和父图对账会非常快，因为不再需要肉眼去图上找每一根箭头。

5.3 最后分享一个非常实用的手艺

在评审大量子图之后，我发现真正老练的分析师不会只看某一张图层层嵌套的美观，而是会做一个“回装动作”。什么叫回装？就是把子图内部所有加工重新看作一个黑盒，只保留子图与外部实体和数据存储之间的全部数据流，然后拿这个黑盒去和父图被展开的那个加工逐流比对。

这个动作做多了以后，你会慢慢产生一种边界感：看到一个加工，心里会自动判断它的输入是否能支撑输出，它展开后是否会引出不属于父图的新边界。灰洞和父子不平衡，通过这种回装动作往往可以在三分钟内被发现。哪怕只是坐在屏幕前用鼠标看图，我也会先在白纸上把父图加工的外部流列成三列，分别是流入、流出、访问存储，然后再去子图里找对应项。

这套方法不挑行业，也不挑具体业务。电商要拆订单履约，银行要拆账务处理，医疗要拆诊疗预约，换汤不换药。真正让数据流图分层建模发挥价值的，不是某个高深工具，而是你是否愿意在每个层级之间认真做一次对账，愿意在评审会上把“这里怎么产生了数据”这个问题追问到底。DFD 画得好的团队，往往不是在画图技巧上胜出，而是在这种较真程度上胜出。