求职门户项目DFD分层设计咨询：各级DFD划分及流程分配疑问
2026-6-26
求职门户企业端已发布职位模块DFD分层设计指南
一级DFD（上下文级）：聚焦整体交互边界
把整个已发布职位模块作为单一处理单元，只展示核心交互的边界与关系：
- 外部实体：企业用户
- 核心处理单元：
已发布职位管理模块 - 数据存储：
- 职位数据库（存储企业所有已发布/未发布职位信息）
- 申请人数据库（存储各职位的申请人信息）
- 关键数据流：
- 企业用户 →
已发布职位管理模块：查看已发布职位请求、职位编辑/删除/详情/申请人列表操作请求 已发布职位管理模块→ 企业用户：已发布职位列表、职位详情页、申请人列表页、操作结果反馈（编辑成功/删除成功等）已发布职位管理模块↔ 职位数据库：读取已发布职位数据、更新/删除职位数据已发布职位管理模块↔ 申请人数据库：读取对应职位的申请人数据
- 企业用户 →
二级DFD：拆解核心处理流程
将一级DFD中的已发布职位管理模块拆分为具体子处理单元，明确每个操作的数据流逻辑：
- 子处理单元1：
已发布职位列表生成- 输入：企业用户的查看请求
- 数据流：从职位数据库读取该企业的已发布职位数据 → 整理为结构化列表 → 返回给企业用户
- 子处理单元2：
职位详情查询- 输入：企业用户选中的职位ID
- 数据流：根据职位ID从职位数据库读取完整职位信息 → 返回职位详情页给用户
- 子处理单元3：
职位编辑处理- 输入：企业用户提交的编辑内容+职位ID
- 数据流：验证编辑内容合法性 → 更新职位数据库对应记录 → 返回编辑结果（成功/失败）给用户
- 子处理单元4：
职位删除处理- 输入：企业用户的删除请求+职位ID
- 数据流：验证企业用户对该职位的操作权限 → 从职位数据库删除对应记录 → 返回删除结果给用户
- 子处理单元5：
申请人列表生成- 输入：企业用户选中的职位ID
- 数据流：根据职位ID从申请人数据库读取关联的申请人数据 → 整理为列表 → 返回申请人列表页给用户
三级DFD的必要性判断
三级DFD仅在二级子处理单元存在多步骤复杂逻辑时才需要制作：
- 无需做三级DFD的情况：如果二级处理单元逻辑简单直接（比如职位删除就是「权限验证→删除数据→反馈结果」三步无分支），无需拆分。
- 需要做三级DFD的情况：如果某个处理有复杂分支或子流程，比如
职位编辑处理包含「权限校验→字段格式校验→重复职位校验→数据更新→日志记录→结果反馈」等多环节，或者申请人列表生成包含「筛选条件处理→分页计算→数据排序→列表生成」等细分步骤，此时可将该二级处理单元拆为三级DFD，明确每个子步骤的数据流。
分层核心原则
- 一级看边界：只关心模块与外部的交互，不涉及内部细节。
- 二级看流程：拆解核心操作的独立处理单元，每个单元对应一个明确功能。
- 三级看细节：仅针对复杂流程做细分，避免过度拆解导致DFD冗余。
内容的提问来源于stack exchange，提问作者Bhakti
相关产品推荐
相关产品推荐
