2. 业务场景梳理与流程节点识别：典型审批场景、节点类型、角色定义

2.1 边界定义：审批流程的上下文与范围

在梳理业务场景之前，必须明确审批流程在企业架构中的位置。审批流不是孤立的技术组件，而是连接业务数据、组织权限和合规策略的执行载体。本课程将围绕以下三层边界展开讨论：

• 组织边界：审批流横跨部门、岗位、职级，需明确上级审批、跨部门会签、指定抄送等规则如何映射到实际组织架构。
• 系统边界：审批流与业务系统（如CRM、ERP）、通知系统（邮件/IM）、审计系统之间存在数据交互，需定义哪些数据由上游系统提供，哪些由审批引擎产生。
• 数据边界：审批单中的字段（金额、类型、申请人部门）决定了审批路径的走向，数据边界决定了哪些字段参与条件判断，哪些仅用于展示。

2.2 典型审批场景分层

根据企业实际运营模式，可将审批场景分为三个层级，每个层级对应不同的节点复杂度与权限约束：

2.3 流程节点类型与职责

在识别具体节点时，需将节点分为流程节点、逻辑节点和控制节点三类，每类节点在数据流和控制流中承担不同职责：

• 流程节点：包括审批节点、会签节点、知会节点。审批节点负责决策，会签节点要求多人一致通过，知会节点仅传递信息，不阻断流程。
• 逻辑节点：包括条件分支节点（基于金额、部门、职级等字段路由）、并行分支节点（并发审批后聚合）、循环节点（退回修改后重审）。
• 控制节点：包括超时自动转交节点、异常挂起节点、驳回终止节点。这些节点负责流程的异常处理与最终一致性保障。

2.4 角色定义与信任链路

角色定义是权限模型落地的关键。在审批流中，角色分为以下三类，其信任链路（即身份验证与授权链路）需在架构层面清晰分开：

2.5 数据流与控制流分析

在审批流程中，数据流和控制流的分离是架构设计的关键。数据流负责审批单的字段传递，控制流负责节点路由的决策。以下通过一个简化结构举例：

• 数据流：前端提交表单 → 业务服务校验 → 流程引擎持久化到数据库（含字段历史版本） → 审批节点读取字段。
• 控制流：流程引擎根据条件分支（如金额 > 10万）动态确定下一节点 → 向审批人发送任务 → 等待响应 → 根据响应（通过/驳回）触发下一决策。

2.6 选型权衡：节点模型与实现策略

2.7 落地步骤：从场景到节点定义

1. 场景清单梳理：与业务方访谈，输出场景列表（含触发条件、期望节点数、审批人条件）。
2. 节点类型归约：将每个场景的节点归约为流程节点、逻辑节点或控制节点。
3. 角色映射：为每个节点定义对应的业务角色/系统角色，并明确信任链路的凭证方式（如用户Token、服务Key）。
4. 边界确认：与上下游系统（组织服务、通知服务、审计服务）确认字段格式、接口协议和异常处理方案。
5. 节点定义固化：将节点模型、角色映射和边界协议写入流程定义文件（如JSON/XML或BPMN模型），并输出交付检查清单。

2.8 验收标准

• 场景覆盖率：所有已识别场景均能在测试环境中按预期走通，节点顺序、角色分配无偏差。
• 节点完整性：每个场景至少包含一个流程节点、一个逻辑节点（或控制节点），不存在“悬挂”节点（无角色或无条件）。
• 角色粒度：所有角色均可追溯至具体的组织单元或服务凭证，无模糊定义。
• 边界测试：模拟上游系统异常（如组织服务超时）、下游系统不可用（如通知失败），流程引擎能正确执行挂起或降级策略。