工作流引擎组织结构设计拆解：五表核心模型与选人机制

本文基于源码静态分析，梳理一套工作流引擎的组织结构设计：五表核心模型的字段语义、与选人引擎的配合，以及与极简二元模型、重度 RBAC 模型的对比。

一、为什么组织结构设计如此重要

1.1 基本定义

组织结构是指：系统运行要依赖的人员、部门、角色，以及人员与部门、角色之间的对应关系。

在该 BPM 平台（该引擎）中，这一概念直接落地为 Port_* 系列数据表，实体类统一归属 引擎内核命名空间 命名空间。流程引擎的节点接收人规则、表单权限、组织隔离、待办推送等能力，均以这套结构为数据底座。

1.2 组织结构是应用系统的基石

组织结构不仅是 BPM 的专属需求，更是整个应用系统的基础，也是权限管理的基本条件：

若组织模型与业务语义不匹配，轻则集成成本陡增，重则流程"找不到人"、权限穿透或数据串租户——这类问题在生产环境中极难补救。

1.3 业界设计的困境

每个架构师对组织结构的理解、应用方向、部署环境各不相同，导致表结构设计千差万别：

• 有的系统只有「用户—部门」二元关系，角色挂在用户上，无法表达"同一人不同部门担任不同岗位"；
• 有的把角色做成全局属性，忽略"财务部经理"与"市场部经理"虽同为"经理"但权责不同的现实；
• 有的为追求范式化拆出十几张表，集成时映射成本极高；
• 有的为图省事把部门、岗位、人员揉进一张宽表，无法支撑树形部门与多组织隔离。

核心矛盾：模型太简单则无法覆盖政企复杂场景；模型太复杂则难以与存量 HR/OA 系统对接。究竟哪种设计能覆盖绝大多数场景？ 这是本报告要回答的问题。

1.4 该平台的命题

该平台结合十余年 BPM 交付与组织结构集成经验，提出一套经过大量项目验证的五表核心模型。其目标不是学术上的"最范式化"，而是：

用尽可能少的表，表达尽可能完整的组织语义，并让整个工作流引擎能用一条 SQL 完成"按部门+角色找人"。

二、该平台五表核心模型

2.1 五表总览

另有扩展表 Port_StationType（角色分类）、Port_Org / Port_OrgAdminer（多组织管理）等，服务于集团/SAAS 模式，不改变五表核心语义。

2.2 实体关系

2.3 各表设计要点（代码印证）

Port_Dept — 部门

• 树形结构：ParentNo 自关联，NameOfPath 冗余全路径以加速展示与检索。
• Leader 存部门领导登录账号（非中文名），直接支撑"找部门负责人"类流程规则。
• OrgNo 在集团/SAAS 模式下做组织隔离。

Port_Emp — 人员

• FK_Dept 表示主部门，满足"此人默认归属哪里"的高频查询。
• SAAS 模式下 UserID 与 No（组织编号_UserID）分离，允许跨租户账号重复。
• Leader 字段支撑"找直属领导"规则，与部门领导字段语义区分清晰。

Port_Station — 角色

• 角色是岗位抽象（如"部门经理""出纳"），不直接绑定人员。
• 通过 FK_StationType 分类，便于流程设计器按类型筛选。
• 集团模式下可通过 GroupStationModel 配置为"组织级角色"或"部门级角色"。

Port_DeptEmp — 部门人员（兼职）

• 主键 MyPK = FK_Dept + "_" + FK_Emp，一人可挂多个部门。
• 删除时级联清理该人员在该部门下的 Port_DeptEmpStation 记录，保证数据一致性。

Port_DeptEmpStation — 三要素绑定（设计灵魂）

• 主键 MyPK = FK_Dept + "_" + FK_Emp + "_" + FK_Station。
• 语义：张三在财务部担任出纳，与张三在市场部担任经理是两条独立记录。
• 这是整个 BPM 选人引擎的核心查询表。

三、设计思想：为什么是五表

3.1 主部门 + 兼职部门的双轨模型

该平台没有强迫所有关系都走关联表，而是采用双轨策略：

这避免了"所有关系都塞进关联表"导致的性能问题，也避免了"只在用户表上挂一个部门字段"无法表达兼职的局限。

3.2 角色必须带部门上下文

这是该平台方案与许多简易 OA 的根本分歧。

简易方案常把角色直接挂在人员上（User.Role = 经理），但现实中：

• 张三在 A 部门是部门经理（可审批本部门费用）；
• 张三在 B 部门是普通员工（只能提交申请）。

若角色不绑定部门，流程引擎无法区分"找 A 部门的经理"与"找 B 部门的经理"。

该平台用 Port_DeptEmpStation 将 部门 × 角色 × 人员 三维绑定，使语义与政企编制管理一致。

3.3 流程引擎的直接受益

FindWorker.cs 中大量接收人规则最终归结为对 Port_DeptEmpStation 的查询。例如"按角色智能计算"的核心 SQL：

引擎内核命名空间.Glo 中的公共选人方法同样依赖此表：

人员是否拥有某角色，也通过此表判断：

设计结论：五表不是"数据库教科书式"的拆表，而是让引擎能用简单 SQL 表达复杂组织语义的最小闭包。

四、与常见设计方案对比

4.1 三种典型路线

4.2 为什么不选"角色直接挂用户"

许多系统采用 UserStation（用户—角色）二元关联。其缺陷在 BPM 场景下会被放大：

1. 无法表达"同一人不同部门不同岗位"——政企兼职极常见；
2. 流程按部门找人时语义模糊——"财务部经理"究竟指哪个部门；
3. 集成时需大量业务规则补偿——在应用层判断"当前流程实例部门"再过滤角色。

该平台在数据模型层一次性解决，使引擎逻辑保持简洁、可测试、可审计。

4.3 为什么不选"十几张表的完整 IAM"

完整身份与访问管理（IAM）模型适合统一身份平台，但对 BPM 集成而言往往过度设计：

• HR 系统通常提供的是部门、人员、岗位，而非 Permission、Resource、Policy；
• 映射链路过长，任一环节不一致即导致"流程找不到人"；
• 运维人员难以理解"为什么这个人有角色但流程选不到"。

该平台五表在表达能力与集成友好度之间取了工程上的平衡点。

五、优劣分析

5.1 优势

5.2 局限与应对

5.3 客观评价

该平台五表模型不是万能的组织架构，而是为 BPM 工作流场景优化的最小完备集：

• 若您的核心需求是"复杂审批流按部门岗位找人、支持兼职、支持多组织"，五表方案高度匹配；
• 若您的核心需求是"细粒度资源权限、零信任策略、跨系统联邦身份"，应在五表之上叠加专业 IAM，而非替换五表；
• 若您的组织极简单（无兼职、无多岗位），五表略显"重"，但集成接口与视图模式使额外成本可控，且为未来业务扩展留有余地。

六、多组织运行模式

五表模型通过 该引擎RunModel 配置项支持三种运行模式，无需修改表结构：

扩展表 Port_Org、Port_OrgAdminer 在集团/SAAS 模式下管理组织生命周期与管理员权限，与五表通过 OrgNo 松耦合。

七、集成实践：两种模式

该平台提供两种组织结构集成路径，均围绕五表展开：

7.1 视图模式（推荐）

删除 该引擎 侧五张物理表，创建同结构视图，将业务库组织数据映射过来。优势：

• 单一数据源，无同步延迟；
• 业务系统改组织，BPM 即时生效；
• 维护成本最低。

7.2 接口模式（数据同步）

通过 OrganizationAPI 在组织变更时主动同步。核心接口：

Port_Emp_Save 的实现体现了五表联动逻辑——一次调用完成 Port_Emp、Port_DeptEmp、Port_DeptEmpStation 的写入：

集成建议：

• 数据库可合并 → 优先视图模式；
• 数据库必须分离 → 接口模式，一人多部门时每个部门各调用一次 Port_Emp_Save。

八、总结

8.1 设计命题回顾