系统架构设计进阶指南 · 结构化需求分析中的数据流图实战

1. 数据流图：从“一团乱麻”到“清晰蓝图”的实战心法

刚入行做系统设计那会儿，我最怕的就是需求分析会。产品经理、业务方、技术团队坐在一起，大家七嘴八舌，这个说要加个功能，那个说流程不对，最后会议记录写了好几页，但系统到底要处理哪些数据、数据从哪里来、到哪里去，脑子里还是一团浆糊。直到我的导师扔给我一张画得歪歪扭扭的图，说：“别急着画架构图，先把这张‘数据流图’搞明白。” 那是我第一次真正理解，一个复杂的系统需求，原来可以像看地图一样清晰。

数据流图，英文叫Data Flow Diagram，我们行内习惯简称DFD。它不是什么高深莫测的数学公式，而是一种极其朴素的“可视化语言”。你可以把它想象成你家的水路图或者电路图：水从哪里进来（水源/实体），经过哪些处理设备（加工/处理），存储在哪个水箱（数据存储），最后又流向哪个水龙头（输出/实体）。数据流图干的就是同样的事，只不过它描绘的是“数据”的流动轨迹。对于系统架构师来说，在动手画技术架构、选型数据库之前，先把数据流图画清楚，就相当于盖楼前先有了精准的施工蓝图，能避免后面无数的“返工”和“扯皮”。

那么，数据流图到底适合谁用？我认为，只要是参与系统构建的人，都应该能看懂、甚至能动手画一画。产品经理可以用它来厘清业务逻辑，和业务方确认需求边界；后端开发可以用它来明确接口职责和数据模型；测试同学可以根据它来设计测试用例，覆盖所有关键的数据流转路径。当然，最核心的使用者还是我们系统架构师。它是我们进行结构化需求分析的核心工具，是把模糊的自然语言需求，转化为严谨、无歧义的技术规格说明书的第一步。接下来，我就结合我踩过的坑和总结的经验，带你从零开始，掌握数据流图在实战中的应用。

2. 拆解DFD核心四要素：实体、加工、数据流与存储

想把数据流图画明白，首先得认全它的四个“基本零件”：外部实体、加工、数据流和数据存储。这四样东西，就像乐高积木，组合方式千变万化，但每个零件本身的概念必须清晰。

### 2.1 外部实体：系统的“边界”与“对话者”

外部实体，就是系统之外，与系统有数据交互的人、物或组织。它是系统的边界。识别实体，就是在回答一个问题：“这个系统在和谁打交道？” 这里有个常见的坑：容易把系统内部模块当成外部实体。比如，我们要设计一个“在线商城系统”，那么“用户”、“仓储系统”、“支付网关”就是典型的外部实体。但“购物车模块”或“订单服务”就不是，它们是系统内部的组成部分。

实体的画法通常是一个矩形框，或者带阴影的矩形。在实战中，我习惯在项目初期，拉着所有干系人一起，把能想到的所有“对话者”都列出来。比如，除了上述几个，可能还有“物流公司接口”、“客服后台”、“风控系统”等等。这个过程本身就能发现很多隐藏的需求点。

### 2.2 加工：数据的“炼金术”与核心逻辑

加工，也叫处理过程，这是DFD的灵魂。它代表了对数据进行的变换操作。一个加工，必须有输入数据流，也必须有输出数据流，它把输入“加工”成了输出。加工的名字，强烈建议使用“动词+名词”的短语，比如“验证用户密码”、“生成订单号”、“计算配送费用”、“发送发货通知”。名字要具体，避免使用“处理”、“管理”这样模糊的词。

在复杂系统中，一个加工可以不断向下分解，形成多层次的DFD。顶层的加工“处理订单”，在下一层可能被分解为“校验库存”、“计算价格”、“创建订单记录”等子加工。这就是结构化分析的“自顶向下，逐层求精”思想。我见过不少新手画的图，加工框里写的是“订单模块”，这其实是一个子系统或模块名，而不是一个具体的处理动作，这是需要避免的。

### 2.3 数据流：流淌的“血液”与信息载体

数据流就是箭头，它表示数据在流动。箭头旁边要标注流动的是什么数据，例如“登录请求”、“用户信息”、“订单详情”、“库存扣减结果”。这里的关键是，数据流必须是“数据包”，而不是物质流或控制流。比如，你不能画一个从“用户”到“系统”的“点击”数据流，但可以画“点击事件数据”或“HTTP请求数据”。

数据流是连接各个元素的纽带。检查数据流是否合理，是验证系统逻辑的重要手段。一个常见的检查点是：每个加工的输出数据流，是否都能从其输入数据流中推导或生成出来？如果发现某个加工凭空产生了一个数据，那很可能漏画了输入流。

### 2.4 数据存储：系统的“记忆”仓库

数据存储，顾名思义，就是数据暂时或永久停留的地方。在图中通常用一条开口的横线或一个圆柱体表示，并注明存储的名称，如“用户表”、“订单数据库”、“商品缓存”。数据存储是介于加工之间的“缓冲区”，一个加工写入数据，另一个加工读取数据。

需要注意的是，数据存储是系统内部的概念，因此它不能直接与外部实体交互，所有进出数据存储的数据流，必须经过加工。例如，“用户”不能直接“读取商品信息”，必须是用户通过“查询商品”这个加工，由加工去读取“商品数据库”，再把结果返回给用户。把握好这一点，能保证图的逻辑严密性。

为了更直观地区分这四要素，我整理了一个快速对照表，你画图时可以放在手边参考：

3. 实战演练：从需求描述到分层DFD绘制

光说不练假把式，我们用一个简化但真实的案例来走一遍流程。假设我们要为一个“社区图书漂流系统”做需求分析。初步的需求描述是这样的：“用户可以在系统上捐赠图书或借阅图书。捐赠时，需要填写图书信息，系统审核后上架。借阅时，用户查找图书，发起借阅请求，图书持有者同意后，双方协商线下交换。系统需要记录图书的漂流轨迹。”

看到这段文字，是不是感觉有点乱？别急，我们一步步来。

### 3.1 第一步：识别顶层图（语境图）

顶层图，也叫0层图或语境图，它的目标是界定系统范围，回答“系统和外界谁交换什么数据”。我们先把整个系统看作一个黑盒子，只关心它和外部实体的交互。

1. 找实体：从描述中，我们能找到“用户”（捐赠和借阅）。“图书持有者”在借阅流程中出现了，但在这个简单模型中，我们可以先将其归为“用户”的一种角色。此外，有没有外部系统？目前看没有。所以，外部实体暂时只有一个：用户。
2. 找数据流：用户对系统做什么？
   • 用户可以向系统捐赠图书（输入：图书信息）。
   • 用户可以从系统借阅图书（输入：借阅请求）。
   • 系统需要向用户返回信息，比如审核结果、可借阅图书列表、借阅请求状态等。

根据以上分析，我们可以画出顶层图。这个图非常简单，只有一个“图书漂流系统”加工，和“用户”实体，以及几条进出的数据流。它明确了系统的边界：所有关于图书漂流的核心功能，都在这个黑盒子里。

### 3.2 第二步：分解顶层加工，绘制0层图

现在，我们打开黑盒子，把“图书漂流系统”这个大的加工分解成几个主要的子功能。根据需求，至少可以分解出以下几个核心加工：

1. 处理图书捐赠：接收用户提交的图书信息，进行审核。
2. 管理图书信息：存储和维护所有图书的状态（待审核、已上架、已借出等）。
3. 处理图书借阅：响应用户的查询和借阅请求，协调借阅流程。
4. 记录漂流轨迹：每当图书状态发生变化（如上架、借出、归还），记录一条日志。

接下来，我们要定义这些加工之间的数据流，以及它们如何与数据存储交互。我们需要引入数据存储了，比如“图书库”（存储图书基本信息）和“漂流记录库”（存储流转日志）。

绘制0层图时，我的习惯是先用便签纸或绘图工具把加工和存储摆出来，然后反复问自己：这个加工要完成工作，需要什么数据？会产生什么数据？比如，“处理图书捐赠”这个加工，它需要输入“图书信息”，输出“审核结果”。同时，它审核通过后，需要向“图书库”写入一条新的图书数据。而“处理图书借阅”加工，需要从“图书库”读取可借阅的图书列表，接收用户的“借阅请求”，然后可能要更新“图书库”中该书的状态为“已借出”，同时向“漂流记录库”写入一条借出记录。

这个过程可能需要反复调整。画完草图后，对照原始需求描述，逐句检查是否每个功能点在图上都有体现。你会发现，最初的描述可能遗漏了“审核”的具体标准，或者“协商线下交换”这个环节系统是否需要介入（比如提供聊天功能或联系方式？）。这些模糊点，正是通过画DFD被暴露出来的，需要在需求阶段就和产品经理澄清。

### 3.3 第三步：继续求精，绘制下层图（如1层图）

对于复杂的加工，我们可以继续分解。比如，0层图中的“处理图书借阅”加工，内部逻辑可能还比较复杂，我们可以把它展开成一张1层图。

“处理图书借阅”可能包含以下子加工：

• 查询图书：根据条件搜索“图书库”，返回列表。
• 发起借阅：验证用户资格，生成借阅请求，并通知图书持有者（这里可能涉及另一个实体或内部消息机制）。
• 处理借阅响应：接收持有者的同意/拒绝反馈，更新借阅状态。
• 完成借阅：确认线下交换完成后，关闭借阅流程，更新图书状态。

每展开一层，我们对系统细节的理解就加深一层。但切记，分解要适度，以“逻辑清晰、便于沟通”为准，不要陷入过度分解的泥潭。通常，分解到每个加工可以用一个简单程序模块（或一个微服务）实现的程度，就差不多了。

4. 核心原则：如何检验你的数据流图是否“平衡”

图画出来了，怎么知道它画得对不对？有没有逻辑漏洞？这就需要用到DFD的“平衡原则”。这是评审数据流图是否正确的金标准，也是我当年踩坑最多的地方。

### 4.1 父子图平衡：数据流的守恒定律

这是最重要的一条原则。子图（下层图）的输入输出数据流，必须与父图中对应加工的输入输出数据流完全匹配。就像你有一个黑盒子（父加工），你说它有两条进水管和一条出水管。当你打开盒子（画子图），里面的管道网络可以很复杂，但整体上，流入这个子图的总水量必须是那两条进水管的水，流出的总水量必须是那条出水管的水，不能多，也不能少。

举个例子，在顶层图中，“图书漂流系统”这个加工有一个输入流叫“图书信息”。那么，在0层图中，必须有一个或多个加工能接收这个“图书信息”流，并且这个流只能从“用户”实体流入，不能从其他地方凭空产生。反之，如果在0层图中，你发现“处理图书捐赠”加工产生了一个“捐赠积分通知”流给用户，但顶层图中并没有这个输出流，那就失衡了。要么是顶层图漏画了，要么是0层图画错了。

### 4.2 加工内部平衡：有进必有出，逻辑要自洽

每个加工本身也要平衡。这意味着：

• 有输入必有输出：一个加工不能只“吃”数据不“吐”数据。比如，你画了一个“记录日志”的加工，它从前面加工接收“错误信息”，那它至少应该输出一个“日志记录成功”的信号（哪怕只是写入存储），或者触发另一个动作。
• 有输出必有输入：数据不能无中生有。加工输出的所有数据，必须能从其输入数据经过逻辑处理得到。例如，一个“计算总价”的加工，如果只有“商品列表”输入，没有“商品单价”输入，它就无法输出正确的“订单总价”。
• 输入足以产生输出：这是更深层次的逻辑平衡。检查输入的数据是否足够完成加工所描述的功能。比如，一个“发送配送短信”的加工，它的输入如果只有“订单号”，而没有“用户手机号”，那这个加工就无法工作。

在实战中，我经常用“数据字典”来辅助平衡检查。为图中每一个关键的数据流和数据存储编写简单的定义，说明其包含的数据项。这样，当检查加工逻辑时，就能清晰地看到输入的数据项是否包含了产生输出数据项所必需的全部信息。

### 4.3 与需求描述匹配：逐句核对，查漏补缺

最后，把你的数据流图打印出来，旁边放着原始的需求文档（或会议纪要），逐行、逐句地进行核对。需求文档里的每一句话，是否都能在图上找到对应的体现？无论是功能、数据、还是约束条件。

这是一个极其有效的查漏方法。很多时候，需求文档里一句看似无关紧要的话，比如“系统需在每日凌晨统计捐赠总量”，就可能对应着一个独立的“生成统计报告”加工，以及一个“统计结果”输出流（给管理员实体）。如果画图时漏掉了，就意味着功能漏掉了。反过来，图上出现的每一个元素，也应该能在需求文档中找到依据或合理的解释。通过这种双向核对，能最大程度地保证需求分析的完整性和准确性，把绝大多数问题消灭在设计阶段。