用户认证系统
使用场景: 记录认证流程的后端工程师或安全分析师
外部：用户 → 登录凭据
处理：认证 → 与用户数据库比对验证
数据存储：用户数据库 → 存储哈希密码和令牌
处理：生成会话 → 写入会话存储
数据存储：会话存储 → 保存活跃会话
处理：返回响应 → 向用户发送令牌或错误信息
外部：审计日志系统 → 接收登录记录
这样组织的原因: 将认证过程画成数据流图，使审计日志记录步骤变得清晰可见——团队在实现登录功能时往往忽略记录失败尝试，直到安全审查时才被迫补上。
真实案例
电商订单处理
使用场景: 记录网店结算流程的系统分析师
外部：客户 → 订单详情和支付信息
处理：验证订单 → 检查商品数据库中的库存
数据存储：商品数据库 → 库存和定价
处理：处理支付 → 发送至支付网关
外部：支付网关 → 返回批准或拒绝
处理：创建订单记录 → 写入订单数据库
数据存储：订单数据库 → 存储已确认订单
处理：通知履约 → 发送至仓库系统
外部：仓库系统 → 触发发货
这样组织的原因: 数据流图揭示出支付处理和库存检查是串行的——如果在收取支付后才检查库存，就有对缺货商品收费的风险。这张图让竞态条件在成为生产 Bug 之前就变得显而易见。
数据分析管道
使用场景: 记录事件追踪管道的数据工程师
外部：Web 应用 → 用户事件（点击、浏览、购买）
处理：事件接入 → 校验并排入事件队列
数据存储：事件队列 → 原始事件流
处理：数据转换 → 清洗和丰富数据
数据存储：数据仓库 → 存储处理后的事件
处理：聚合指标 → 计算每日/每周汇总
数据存储：指标存储 → 保存聚合结果
外部：数据大屏 → 从指标存储读取数据
这样组织的原因: 将原始事件队列和处理后的数据仓库设为独立的存储，使得重放历史数据成为可能——跳过这一区分的团队，在转换逻辑发生变化时往往无法重新处理历史数据。
两个系统间的 API 集成
使用场景: 对接两个第三方系统的集成工程师或架构师
外部：源系统 → 数据变更时发送 Webhook
处理：接收 Webhook → 验证签名和载荷
数据存储：集成日志 → 记录所有传入事件
处理：字段映射 → 将源格式转换为目标格式
处理：调用目标 API → 发送转换后的数据
外部：目标系统 → 返回确认或错误
处理：处理响应 → 失败时重试，记录结果
这样组织的原因: 集成日志这个数据存储是大多数团队最容易遗漏的——没有它，调试同步失败就需要查询两个系统并逐条比对记录。数据流图让日志记录成为主动的设计决策，而不是事后补丁。
内容管理与发布
使用场景: 规划 CMS 架构的 CTO 或技术负责人
外部：作者 → 提交草稿内容
处理：审核工作流 → 路由至编辑或发布者
数据存储：草稿库 → 存储未发布内容
处理：审批并发布 → 将内容移至已发布数据库
数据存储：已发布数据库 → 正式内容
处理：内容分发 → 通过 CDN 提供服务
外部：读者 → 接收已发布页面
外部：搜索索引器 → 从已发布数据库读取
这样组织的原因: 将搜索索引器列为外部实体，明确了发布操作会触发索引副作用。未做此建模的团队往往发现内容已上线但未被索引，或在发布前就被索引。
IoT 传感器数据采集
使用场景: 设计传感器管道的嵌入式系统或平台工程师
外部：传感器设备 → 原始读数（温度、压力等）
处理：采集读数 → 校验并添加时间戳
数据存储：原始数据存储 → 保存未处理的传感器输出
处理：检测异常 → 与阈值比对
处理：聚合读数 → 计算每小时平均值
数据存储：处理数据存储 → 存储清洗后的聚合数据
外部：告警系统 → 异常时收到通知
外部：数据大屏 → 可视化处理后的数据
这样组织的原因: 将异常检测和数据聚合设为两个独立的处理过程，意味着它们可以独立运行——异常告警实时触发，而聚合按较慢的调度执行。这个设计决策在数据流图中一目了然，在文字文档里却很容易被忽视。
使用技巧
- 每条箭头都要标注所传递数据的名称，而不只是方向——没有标注的数据流让没有参与绘图的人完全看不懂。
- 没有输出的处理过程是死路，没有输入的处理过程什么也做不了。完成图表前检查每一个处理过程方框。
- 先用上下文图（0 级）展示系统边界，再将每个处理过程展开为详细图（1 级）——不要试图在一张图里展示所有细节。
- 如果数据流跨越信任边界（内部到外部、面向用户到后端），标注出来——这些跨越点正是安全控制应该存在的地方。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=data-flow
使用这个模板