驰骋低代码 BPM 组织结构设计 — 技术报告文档版本2026-06章节编号3.1依据代码CCFlow/Components/BP.En30/Port组织实体、CCFlow/Components/BP.WF/Port/OrganizationAPI.cs同步接口、CCFlow/Components/BP.WF/Template/FindWorker.cs流程选人引擎说明本文基于源码静态分析撰写用于技术分享与方案论证力求准确描述设计思想并客观分析优劣。一、为什么组织结构设计如此重要1.1 基本定义组织结构是指系统运行要依赖的人员、部门、角色以及人员与部门、角色之间的对应关系。在驰骋 BPMCCBPM中这一概念直接落地为Port_*系列数据表实体类统一归属BP.Port命名空间。流程引擎的节点接收人规则、表单权限、组织隔离、待办推送等能力均以这套结构为数据底座。1.2 组织结构是应用系统的基石组织结构不仅是 BPM 的专属需求更是整个应用系统的基础也是权限管理的基本条件依赖方典型场景工作流引擎按部门 角色计算下一节点处理人权限体系按部门、岗位控制菜单、数据范围低代码平台组织树选人、按组织隔离应用与流程第三方集成HR/OA 主数据向 BPM 同步或映射若组织模型与业务语义不匹配轻则集成成本陡增重则流程找不到人、权限穿透或数据串租户——这类问题在生产环境中极难补救。1.3 业界设计的困境每个架构师对组织结构的理解、应用方向、部署环境各不相同导致表结构设计千差万别有的系统只有「用户—部门」二元关系角色挂在用户上无法表达同一人不同部门担任不同岗位有的把角色做成全局属性忽略财务部经理与市场部经理虽同为经理但权责不同的现实有的为追求范式化拆出十几张表集成时映射成本极高有的为图省事把部门、岗位、人员揉进一张宽表无法支撑树形部门与多组织隔离。核心矛盾模型太简单则无法覆盖政企复杂场景模型太复杂则难以与存量 HR/OA 系统对接。究竟哪种设计能覆盖绝大多数场景这是本报告要回答的问题。1.4 驰骋的命题驰骋结合十余年 BPM 交付与组织结构集成经验提出一套经过大量项目验证的五表核心模型。其目标不是学术上的最范式化而是用尽可能少的表表达尽可能完整的组织语义并让整个工作流引擎能用一条 SQL 完成按部门角色找人。二、驰骋五表核心模型2.1 五表总览#表名实体类职责1Port_DeptDept部门树2Port_EmpEmp人员主档3Port_StationStation角色岗位4Port_DeptEmpDeptEmp部门—人员支持兼职5Port_DeptEmpStationDeptEmpStation部门—角色—人员三要素绑定另有扩展表Port_StationType角色分类、Port_Org/Port_OrgAdminer多组织管理等服务于集团/SAAS 模式不改变五表核心语义。2.2 实体关系ParentNo 树形FK_Dept 主部门FK_DeptFK_EmpFK_StationTypeFK_DeptFK_EmpFK_StationPort_DeptPort_EmpPort_DeptEmpPort_StationTypePort_StationPort_DeptEmpStation2.3 各表设计要点代码印证Port_Dept — 部门Map map new Map(Port_Dept, 部门); map.ItIsEnableVer true; map.AddTBStringPK(DeptAttr.No, null, 编号, true, false, 1, 50, 20); map.AddTBString(DeptAttr.Name, null, 名称, true, false, 0, 100, 30); map.AddTBString(DeptAttr.NameOfPath, null, 部门路径, true, false, 0, 100, 30); map.AddTBString(DeptAttr.ParentNo, null, 父节点编号, true, true, 0, 100, 30); map.AddTBString(DeptAttr.OrgNo, null, OrgNo, true, true, 0, 50, 30); map.AddTBString(DeptAttr.Leader, null, 部门领导, true, true,0,50,100);树形结构ParentNo自关联NameOfPath冗余全路径以加速展示与检索。Leader存部门领导登录账号非中文名直接支撑找部门负责人类流程规则。OrgNo在集团/SAAS 模式下做组织隔离。Port_Emp — 人员map.AddTBStringPK(EmpAttr.No, null, 编号, true, false, 1, 50, 30); //如果是集团模式或者是SAAS模式. if (BP.Difference.SystemConfig.CCBPMRunModel CCBPMRunModel.SAAS) map.AddTBString(EmpAttr.UserID, null, 用户ID, true, false, 0, 50, 30); map.AddTBString(EmpAttr.Name, null, 名称, true, false, 0, 200, 30); map.AddTBString(EmpAttr.PinYin, null, 拼音, false, false, 0, 200, 30); map.AddDDLEntities(EmpAttr.FK_Dept, null, 部门, new BP.Port.Depts(), false); map.AddTBString(EmpAttr.Tel, null, 手机号, false, false, 0, 20, 20); map.AddTBString(EmpAttr.Email, null, 邮箱, false, false, 0, 50, 50); map.AddTBString(EmpAttr.Leader, null, 直属部门领导, false, false, 0, 20, 130); map.SetHelperAlert(EmpAttr.Leader, 这里是领导的登录帐号不是中文名字用于流程的接受人规则中。); map.AddTBString(EmpAttr.LeaderName, null, 领导名, true, true, 0, 20, 130); map.AddTBString(EmpAttr.OrgNo, null, 组织编号, true, true, 0, 50, 50);FK_Dept表示主部门满足此人默认归属哪里的高频查询。SAAS 模式下UserID与No组织编号_UserID分离允许跨租户账号重复。Leader字段支撑找直属领导规则与部门领导字段语义区分清晰。Port_Station — 角色Map map new Map(Port_Station, 角色); // map.setCodeStruct(3); // map.setIsAutoGenerNo(true); map.AddTBStringPK(StationAttr.No, null, 编号, true, true, 1, 50, 200); map.AddTBString(StationAttr.Name, null, 名称, true, false, 0, 100, 200); map.AddDDLEntities(StationAttr.FK_StationType, null, 类型, new StationTypes(), true); map.AddTBString(StationAttr.OrgNo, null, 隶属组织, false, false, 0, 50, 250);角色是岗位抽象如部门经理“出纳”不直接绑定人员。通过FK_StationType分类便于流程设计器按类型筛选。集团模式下可通过GroupStationModel配置为组织级角色或部门级角色。Port_DeptEmp — 部门人员兼职Map map new Map(Port_DeptEmp, 部门人员信息); map.IndexField DeptEmpAttr.FK_Dept; map.AddMyPK(); map.AddTBString(DeptEmpAttr.FK_Dept, null, 部门, false, false, 1, 50, 1); map.AddDDLEntities(DeptEmpAttr.FK_Emp, null, 操作员, new BP.Port.Emps(), false); map.AddTBString(DeptEmpAttr.OrgNo, null, 组织编码, false, false, 0, 50, 50);主键MyPK FK_Dept _ FK_Emp一人可挂多个部门。删除时级联清理该人员在该部门下的Port_DeptEmpStation记录保证数据一致性。Port_DeptEmpStation — 三要素绑定设计灵魂Map map new Map(Port_DeptEmpStation, 部门角色人员对应); map.AddTBStringPK(MyPK, null, 主键MyPK, false, true, 1, 150, 10); map.AddTBString(DeptEmpStationAttr.FK_Dept, null, 部门, true, true, 1, 100, 1); map.AddTBString(DeptEmpStationAttr.FK_Station, null, 角色, true, true, 1, 50, 1); map.AddTBString(DeptEmpStationAttr.FK_Emp, null, 操作员, true, true, 1, 100, 1); map.AddTBString(DeptEmpAttr.OrgNo, null, 组织编码, true, true, 0, 50, 50);主键MyPK FK_Dept _ FK_Emp _ FK_Station。语义张三在财务部担任出纳与张三在市场部担任经理是两条独立记录。这是整个 BPM 选人引擎的核心查询表。三、设计思想为什么是五表3.1 主部门 兼职部门的双轨模型驰骋没有强迫所有关系都走关联表而是采用双轨策略场景使用表原因默认部门、快速查人Port_Emp.FK_Dept单表查询性能最优一人多部门兼职Port_DeptEmp不破坏主部门字段的简洁性部门内岗位绑定Port_DeptEmpStation角色必须带部门上下文这避免了所有关系都塞进关联表导致的性能问题也避免了只在用户表上挂一个部门字段无法表达兼职的局限。3.2 角色必须带部门上下文这是驰骋方案与许多简易 OA 的根本分歧。简易方案常把角色直接挂在人员上User.Role 经理但现实中张三在 A 部门是部门经理可审批本部门费用张三在 B 部门是普通员工只能提交申请。若角色不绑定部门流程引擎无法区分找 A 部门的经理与找 B 部门的经理。驰骋用Port_DeptEmpStation将部门 × 角色 × 人员三维绑定使语义与政企编制管理一致。3.3 流程引擎的直接受益FindWorker.cs中大量接收人规则最终归结为对Port_DeptEmpStation的查询。例如按角色智能计算的核心 SQLstring sql1 SELECT FK_Emp FROM Port_DeptEmpStation WHERE FK_Station stas AND FK_Dept depts ;// sqlEnd; return DBAccess.RunSQLReturnTable(sql1);BP.Port.Glo中的公共选人方法同样依赖此表string sql SELECT B.No,B.Name FROM Port_DeptEmpStation A,Port_Emp B WHERE A.FK_Station IN ( GenerWhereInSQL(stationNos) ) AND A.FK_Dept IN ( BP.Port.Glo.GenerWhereInSQL(deptNos) ) AND A.FK_EmpB.No;人员是否拥有某角色也通过此表判断public bool HaveStation(string stationNo) { string sql SELECT COUNT(FK_Emp) AS Num FROM Port_DeptEmpStation WHERE FK_Emp this.No AND FK_Station stationNo ; if (DBAccess.RunSQLReturnValInt(sql) 0) return false; return true; }设计结论五表不是数据库教科书式的拆表而是让引擎能用简单 SQL 表达复杂组织语义的最小闭包。四、与常见设计方案对比4.1 三种典型路线方案C重度 RBACUserUserRoleRoleRolePermissionPermissionUserDeptDept方案B驰骋五表EmpDeptDeptEmpDeptEmpStationStation方案A极简二元UserDept维度方案A用户—部门方案B驰骋五表方案C重度 RBAC表数量235核心815兼职部门不支持或 hack原生支持需额外建模部门上下文角色不支持原生支持需 RoleScope 扩展BPM 选人 SQL 复杂度高需业务层拼装低单表/双表 JOIN高多表 JOIN 范围判断与 HR 主数据映射简单但不完整中等语义对齐复杂概念不对等权限细粒度弱中角色部门强资源级 ACL集成维护成本低中高4.2 为什么不选角色直接挂用户许多系统采用UserStation用户—角色二元关联。其缺陷在 BPM 场景下会被放大无法表达同一人不同部门不同岗位——政企兼职极常见流程按部门找人时语义模糊——财务部经理究竟指哪个部门集成时需大量业务规则补偿——在应用层判断当前流程实例部门再过滤角色。驰骋在数据模型层一次性解决使引擎逻辑保持简洁、可测试、可审计。4.3 为什么不选十几张表的完整 IAM完整身份与访问管理IAM模型适合统一身份平台但对 BPM 集成而言往往过度设计HR 系统通常提供的是部门、人员、岗位而非 Permission、Resource、Policy映射链路过长任一环节不一致即导致流程找不到人运维人员难以理解为什么这个人有角色但流程选不到。驰骋五表在表达能力与集成友好度之间取了工程上的平衡点。五、优劣分析5.1 优势优势说明语义贴近政企编制部门树 岗位 兼职与真实组织管理一致业务人员易理解BPM 原生适配FindWorker引擎直接查询Port_DeptEmpStation无需应用层翻译集成面收敛视图/接口集成都只需对齐五表文档与 API 边界清晰多组织可扩展通过OrgNo字段贯通五表单组织到 SAAS 无需改模型双轨性能主部门走Port_Emp.FK_Dept快速查询复杂关系走关联表级联一致性DeptEmp删除自动清理DeptEmpStation减少脏数据经大量项目验证OrganizationAPI提供完整增删改同步能力降低对接风险5.2 局限与应对局限影响驰骋的应对五表同步成本外部 HR 需维护 DeptEmp DeptEmpStation提供Port_Emp_Save一次调用写入三表推荐视图模式合并库角色非全局全公司总监类岗位需特殊处理可用虚拟部门、或按组织根部门绑定角色冗余字段NameOfPath、DeptEmp 中 Vue3 辅助列换取查询性能与前端展示便利复合主键MyPK拼接规则在 SAAS 下有变体统一由实体beforeUpdateInsertAction生成集成时调用 API 即可非完整 IAM不支持资源级 ACL、动态策略权限场景由应用系统承担BPM 聚焦流程选人标签/用户组非核心Port_Team系列为辅助不影响五表主模型按需启用5.3 客观评价驰骋五表模型不是万能的组织架构而是为 BPM 工作流场景优化的最小完备集若您的核心需求是复杂审批流按部门岗位找人、支持兼职、支持多组织五表方案高度匹配若您的核心需求是细粒度资源权限、零信任策略、跨系统联邦身份应在五表之上叠加专业 IAM而非替换五表若您的组织极简单无兼职、无多岗位五表略显重但集成接口与视图模式使额外成本可控且为未来业务扩展留有余地。六、多组织运行模式五表模型通过CCBPMRunModel配置项支持三种运行模式无需修改表结构值模式组织特征0单组织无OrgNo隔离一个admin管理全部1集团组织多独立组织OrgNo隔离用户账号全局唯一可共享流程2SAAS多租户账号可跨租户重复Emp.UserIDEmp.No双字段扩展表Port_Org、Port_OrgAdminer在集团/SAAS 模式下管理组织生命周期与管理员权限与五表通过OrgNo松耦合。七、集成实践两种模式驰骋提供两种组织结构集成路径均围绕五表展开7.1 视图模式推荐删除 CCBPM 侧五张物理表创建同结构视图将业务库组织数据映射过来。优势单一数据源无同步延迟业务系统改组织BPM 即时生效维护成本最低。7.2 接口模式数据同步通过OrganizationAPI在组织变更时主动同步。核心接口接口作用Port_Org_Save同步组织及主管理员Port_Dept_Save/Port_Dept_Delete同步部门Port_Emp_Save/Port_Emp_Delete同步人员及部门角色关系Port_Station_Save/Port_Station_Delete同步角色Port_Emp_Save的实现体现了五表联动逻辑——一次调用完成Port_Emp、Port_DeptEmp、Port_DeptEmpStation的写入//插入部门. BP.Port.DeptEmp de new BP.Port.DeptEmp(); de.MyPK de.DeptNo _ userNo; //更新角色. if (stats null) stats ; string[] strs stats.Split(,); // ... DeptEmpStation des new DeptEmpStation(); des.DeptNo deptNo; des.EmpNo userNo; des.StationNo str; des.OrgNo orgNo; des.MyPK de.DeptNo _ des.EmpNo _ des.StationNo; des.DirectInsert();集成建议数据库可合并 → 优先视图模式数据库必须分离 → 接口模式一人多部门时每个部门各调用一次Port_Emp_Save。八、总结8.1 设计命题回顾#命题驰骋的回答1组织结构是什么人员、部门、角色及其对应关系2为何重要应用系统基础权限与流程的前提3为何设计千差万别场景、环境、理解差异导致模型分化4哪种设计覆盖大多数场景五表核心模型经大量政企项目验证5五表是什么Dept、Emp、Station、DeptEmp、DeptEmpStation6优劣如何流程语义完备、集成面收敛非完整 IAM同步需规范7如何落地视图模式或 OrganizationAPI按部署条件选择8.2 一句话概括驰骋 BPM 用五张表把谁在哪个部门担任什么角色这一政企最核心的组织语义数据结构化了使整个工作流引擎能用简洁 SQL 完成复杂选人——这是多年集成经验沉淀下的工程选择而非纸上谈兵。8.3 延伸阅读组织结构数据字典与运行模式doc/组织结构.md工作流引擎整体技术白皮书doc/驰骋BPM工作流引擎技术白皮书2026版.md本文档由驰骋 BPM 技术团队基于源码分析编写转载请注明出处。
驰骋BPM组织结构设计技术报告
发布时间：2026/6/18 17:18:31
驰骋低代码 BPM 组织结构设计 — 技术报告文档版本2026-06章节编号3.1依据代码CCFlow/Components/BP.En30/Port组织实体、CCFlow/Components/BP.WF/Port/OrganizationAPI.cs同步接口、CCFlow/Components/BP.WF/Template/FindWorker.cs流程选人引擎说明本文基于源码静态分析撰写用于技术分享与方案论证力求准确描述设计思想并客观分析优劣。一、为什么组织结构设计如此重要1.1 基本定义组织结构是指系统运行要依赖的人员、部门、角色以及人员与部门、角色之间的对应关系。在驰骋 BPMCCBPM中这一概念直接落地为Port_*系列数据表实体类统一归属BP.Port命名空间。流程引擎的节点接收人规则、表单权限、组织隔离、待办推送等能力均以这套结构为数据底座。1.2 组织结构是应用系统的基石组织结构不仅是 BPM 的专属需求更是整个应用系统的基础也是权限管理的基本条件依赖方典型场景工作流引擎按部门 角色计算下一节点处理人权限体系按部门、岗位控制菜单、数据范围低代码平台组织树选人、按组织隔离应用与流程第三方集成HR/OA 主数据向 BPM 同步或映射若组织模型与业务语义不匹配轻则集成成本陡增重则流程找不到人、权限穿透或数据串租户——这类问题在生产环境中极难补救。1.3 业界设计的困境每个架构师对组织结构的理解、应用方向、部署环境各不相同导致表结构设计千差万别有的系统只有「用户—部门」二元关系角色挂在用户上无法表达同一人不同部门担任不同岗位有的把角色做成全局属性忽略财务部经理与市场部经理虽同为经理但权责不同的现实有的为追求范式化拆出十几张表集成时映射成本极高有的为图省事把部门、岗位、人员揉进一张宽表无法支撑树形部门与多组织隔离。核心矛盾模型太简单则无法覆盖政企复杂场景模型太复杂则难以与存量 HR/OA 系统对接。究竟哪种设计能覆盖绝大多数场景这是本报告要回答的问题。1.4 驰骋的命题驰骋结合十余年 BPM 交付与组织结构集成经验提出一套经过大量项目验证的五表核心模型。其目标不是学术上的最范式化而是用尽可能少的表表达尽可能完整的组织语义并让整个工作流引擎能用一条 SQL 完成按部门角色找人。二、驰骋五表核心模型2.1 五表总览#表名实体类职责1Port_DeptDept部门树2Port_EmpEmp人员主档3Port_StationStation角色岗位4Port_DeptEmpDeptEmp部门—人员支持兼职5Port_DeptEmpStationDeptEmpStation部门—角色—人员三要素绑定另有扩展表Port_StationType角色分类、Port_Org/Port_OrgAdminer多组织管理等服务于集团/SAAS 模式不改变五表核心语义。2.2 实体关系ParentNo 树形FK_Dept 主部门FK_DeptFK_EmpFK_StationTypeFK_DeptFK_EmpFK_StationPort_DeptPort_EmpPort_DeptEmpPort_StationTypePort_StationPort_DeptEmpStation2.3 各表设计要点代码印证Port_Dept — 部门Map map new Map(Port_Dept, 部门); map.ItIsEnableVer true; map.AddTBStringPK(DeptAttr.No, null, 编号, true, false, 1, 50, 20); map.AddTBString(DeptAttr.Name, null, 名称, true, false, 0, 100, 30); map.AddTBString(DeptAttr.NameOfPath, null, 部门路径, true, false, 0, 100, 30); map.AddTBString(DeptAttr.ParentNo, null, 父节点编号, true, true, 0, 100, 30); map.AddTBString(DeptAttr.OrgNo, null, OrgNo, true, true, 0, 50, 30); map.AddTBString(DeptAttr.Leader, null, 部门领导, true, true,0,50,100);树形结构ParentNo自关联NameOfPath冗余全路径以加速展示与检索。Leader存部门领导登录账号非中文名直接支撑找部门负责人类流程规则。OrgNo在集团/SAAS 模式下做组织隔离。Port_Emp — 人员map.AddTBStringPK(EmpAttr.No, null, 编号, true, false, 1, 50, 30); //如果是集团模式或者是SAAS模式. if (BP.Difference.SystemConfig.CCBPMRunModel CCBPMRunModel.SAAS) map.AddTBString(EmpAttr.UserID, null, 用户ID, true, false, 0, 50, 30); map.AddTBString(EmpAttr.Name, null, 名称, true, false, 0, 200, 30); map.AddTBString(EmpAttr.PinYin, null, 拼音, false, false, 0, 200, 30); map.AddDDLEntities(EmpAttr.FK_Dept, null, 部门, new BP.Port.Depts(), false); map.AddTBString(EmpAttr.Tel, null, 手机号, false, false, 0, 20, 20); map.AddTBString(EmpAttr.Email, null, 邮箱, false, false, 0, 50, 50); map.AddTBString(EmpAttr.Leader, null, 直属部门领导, false, false, 0, 20, 130); map.SetHelperAlert(EmpAttr.Leader, 这里是领导的登录帐号不是中文名字用于流程的接受人规则中。); map.AddTBString(EmpAttr.LeaderName, null, 领导名, true, true, 0, 20, 130); map.AddTBString(EmpAttr.OrgNo, null, 组织编号, true, true, 0, 50, 50);FK_Dept表示主部门满足此人默认归属哪里的高频查询。SAAS 模式下UserID与No组织编号_UserID分离允许跨租户账号重复。Leader字段支撑找直属领导规则与部门领导字段语义区分清晰。Port_Station — 角色Map map new Map(Port_Station, 角色); // map.setCodeStruct(3); // map.setIsAutoGenerNo(true); map.AddTBStringPK(StationAttr.No, null, 编号, true, true, 1, 50, 200); map.AddTBString(StationAttr.Name, null, 名称, true, false, 0, 100, 200); map.AddDDLEntities(StationAttr.FK_StationType, null, 类型, new StationTypes(), true); map.AddTBString(StationAttr.OrgNo, null, 隶属组织, false, false, 0, 50, 250);角色是岗位抽象如部门经理“出纳”不直接绑定人员。通过FK_StationType分类便于流程设计器按类型筛选。集团模式下可通过GroupStationModel配置为组织级角色或部门级角色。Port_DeptEmp — 部门人员兼职Map map new Map(Port_DeptEmp, 部门人员信息); map.IndexField DeptEmpAttr.FK_Dept; map.AddMyPK(); map.AddTBString(DeptEmpAttr.FK_Dept, null, 部门, false, false, 1, 50, 1); map.AddDDLEntities(DeptEmpAttr.FK_Emp, null, 操作员, new BP.Port.Emps(), false); map.AddTBString(DeptEmpAttr.OrgNo, null, 组织编码, false, false, 0, 50, 50);主键MyPK FK_Dept _ FK_Emp一人可挂多个部门。删除时级联清理该人员在该部门下的Port_DeptEmpStation记录保证数据一致性。Port_DeptEmpStation — 三要素绑定设计灵魂Map map new Map(Port_DeptEmpStation, 部门角色人员对应); map.AddTBStringPK(MyPK, null, 主键MyPK, false, true, 1, 150, 10); map.AddTBString(DeptEmpStationAttr.FK_Dept, null, 部门, true, true, 1, 100, 1); map.AddTBString(DeptEmpStationAttr.FK_Station, null, 角色, true, true, 1, 50, 1); map.AddTBString(DeptEmpStationAttr.FK_Emp, null, 操作员, true, true, 1, 100, 1); map.AddTBString(DeptEmpAttr.OrgNo, null, 组织编码, true, true, 0, 50, 50);主键MyPK FK_Dept _ FK_Emp _ FK_Station。语义张三在财务部担任出纳与张三在市场部担任经理是两条独立记录。这是整个 BPM 选人引擎的核心查询表。三、设计思想为什么是五表3.1 主部门 兼职部门的双轨模型驰骋没有强迫所有关系都走关联表而是采用双轨策略场景使用表原因默认部门、快速查人Port_Emp.FK_Dept单表查询性能最优一人多部门兼职Port_DeptEmp不破坏主部门字段的简洁性部门内岗位绑定Port_DeptEmpStation角色必须带部门上下文这避免了所有关系都塞进关联表导致的性能问题也避免了只在用户表上挂一个部门字段无法表达兼职的局限。3.2 角色必须带部门上下文这是驰骋方案与许多简易 OA 的根本分歧。简易方案常把角色直接挂在人员上User.Role 经理但现实中张三在 A 部门是部门经理可审批本部门费用张三在 B 部门是普通员工只能提交申请。若角色不绑定部门流程引擎无法区分找 A 部门的经理与找 B 部门的经理。驰骋用Port_DeptEmpStation将部门 × 角色 × 人员三维绑定使语义与政企编制管理一致。3.3 流程引擎的直接受益FindWorker.cs中大量接收人规则最终归结为对Port_DeptEmpStation的查询。例如按角色智能计算的核心 SQLstring sql1 SELECT FK_Emp FROM Port_DeptEmpStation WHERE FK_Station stas AND FK_Dept depts ;// sqlEnd; return DBAccess.RunSQLReturnTable(sql1);BP.Port.Glo中的公共选人方法同样依赖此表string sql SELECT B.No,B.Name FROM Port_DeptEmpStation A,Port_Emp B WHERE A.FK_Station IN ( GenerWhereInSQL(stationNos) ) AND A.FK_Dept IN ( BP.Port.Glo.GenerWhereInSQL(deptNos) ) AND A.FK_EmpB.No;人员是否拥有某角色也通过此表判断public bool HaveStation(string stationNo) { string sql SELECT COUNT(FK_Emp) AS Num FROM Port_DeptEmpStation WHERE FK_Emp this.No AND FK_Station stationNo ; if (DBAccess.RunSQLReturnValInt(sql) 0) return false; return true; }设计结论五表不是数据库教科书式的拆表而是让引擎能用简单 SQL 表达复杂组织语义的最小闭包。四、与常见设计方案对比4.1 三种典型路线方案C重度 RBACUserUserRoleRoleRolePermissionPermissionUserDeptDept方案B驰骋五表EmpDeptDeptEmpDeptEmpStationStation方案A极简二元UserDept维度方案A用户—部门方案B驰骋五表方案C重度 RBAC表数量235核心815兼职部门不支持或 hack原生支持需额外建模部门上下文角色不支持原生支持需 RoleScope 扩展BPM 选人 SQL 复杂度高需业务层拼装低单表/双表 JOIN高多表 JOIN 范围判断与 HR 主数据映射简单但不完整中等语义对齐复杂概念不对等权限细粒度弱中角色部门强资源级 ACL集成维护成本低中高4.2 为什么不选角色直接挂用户许多系统采用UserStation用户—角色二元关联。其缺陷在 BPM 场景下会被放大无法表达同一人不同部门不同岗位——政企兼职极常见流程按部门找人时语义模糊——财务部经理究竟指哪个部门集成时需大量业务规则补偿——在应用层判断当前流程实例部门再过滤角色。驰骋在数据模型层一次性解决使引擎逻辑保持简洁、可测试、可审计。4.3 为什么不选十几张表的完整 IAM完整身份与访问管理IAM模型适合统一身份平台但对 BPM 集成而言往往过度设计HR 系统通常提供的是部门、人员、岗位而非 Permission、Resource、Policy映射链路过长任一环节不一致即导致流程找不到人运维人员难以理解为什么这个人有角色但流程选不到。驰骋五表在表达能力与集成友好度之间取了工程上的平衡点。五、优劣分析5.1 优势优势说明语义贴近政企编制部门树 岗位 兼职与真实组织管理一致业务人员易理解BPM 原生适配FindWorker引擎直接查询Port_DeptEmpStation无需应用层翻译集成面收敛视图/接口集成都只需对齐五表文档与 API 边界清晰多组织可扩展通过OrgNo字段贯通五表单组织到 SAAS 无需改模型双轨性能主部门走Port_Emp.FK_Dept快速查询复杂关系走关联表级联一致性DeptEmp删除自动清理DeptEmpStation减少脏数据经大量项目验证OrganizationAPI提供完整增删改同步能力降低对接风险5.2 局限与应对局限影响驰骋的应对五表同步成本外部 HR 需维护 DeptEmp DeptEmpStation提供Port_Emp_Save一次调用写入三表推荐视图模式合并库角色非全局全公司总监类岗位需特殊处理可用虚拟部门、或按组织根部门绑定角色冗余字段NameOfPath、DeptEmp 中 Vue3 辅助列换取查询性能与前端展示便利复合主键MyPK拼接规则在 SAAS 下有变体统一由实体beforeUpdateInsertAction生成集成时调用 API 即可非完整 IAM不支持资源级 ACL、动态策略权限场景由应用系统承担BPM 聚焦流程选人标签/用户组非核心Port_Team系列为辅助不影响五表主模型按需启用5.3 客观评价驰骋五表模型不是万能的组织架构而是为 BPM 工作流场景优化的最小完备集若您的核心需求是复杂审批流按部门岗位找人、支持兼职、支持多组织五表方案高度匹配若您的核心需求是细粒度资源权限、零信任策略、跨系统联邦身份应在五表之上叠加专业 IAM而非替换五表若您的组织极简单无兼职、无多岗位五表略显重但集成接口与视图模式使额外成本可控且为未来业务扩展留有余地。六、多组织运行模式五表模型通过CCBPMRunModel配置项支持三种运行模式无需修改表结构值模式组织特征0单组织无OrgNo隔离一个admin管理全部1集团组织多独立组织OrgNo隔离用户账号全局唯一可共享流程2SAAS多租户账号可跨租户重复Emp.UserIDEmp.No双字段扩展表Port_Org、Port_OrgAdminer在集团/SAAS 模式下管理组织生命周期与管理员权限与五表通过OrgNo松耦合。七、集成实践两种模式驰骋提供两种组织结构集成路径均围绕五表展开7.1 视图模式推荐删除 CCBPM 侧五张物理表创建同结构视图将业务库组织数据映射过来。优势单一数据源无同步延迟业务系统改组织BPM 即时生效维护成本最低。7.2 接口模式数据同步通过OrganizationAPI在组织变更时主动同步。核心接口接口作用Port_Org_Save同步组织及主管理员Port_Dept_Save/Port_Dept_Delete同步部门Port_Emp_Save/Port_Emp_Delete同步人员及部门角色关系Port_Station_Save/Port_Station_Delete同步角色Port_Emp_Save的实现体现了五表联动逻辑——一次调用完成Port_Emp、Port_DeptEmp、Port_DeptEmpStation的写入//插入部门. BP.Port.DeptEmp de new BP.Port.DeptEmp(); de.MyPK de.DeptNo _ userNo; //更新角色. if (stats null) stats ; string[] strs stats.Split(,); // ... DeptEmpStation des new DeptEmpStation(); des.DeptNo deptNo; des.EmpNo userNo; des.StationNo str; des.OrgNo orgNo; des.MyPK de.DeptNo _ des.EmpNo _ des.StationNo; des.DirectInsert();集成建议数据库可合并 → 优先视图模式数据库必须分离 → 接口模式一人多部门时每个部门各调用一次Port_Emp_Save。八、总结8.1 设计命题回顾#命题驰骋的回答1组织结构是什么人员、部门、角色及其对应关系2为何重要应用系统基础权限与流程的前提3为何设计千差万别场景、环境、理解差异导致模型分化4哪种设计覆盖大多数场景五表核心模型经大量政企项目验证5五表是什么Dept、Emp、Station、DeptEmp、DeptEmpStation6优劣如何流程语义完备、集成面收敛非完整 IAM同步需规范7如何落地视图模式或 OrganizationAPI按部署条件选择8.2 一句话概括驰骋 BPM 用五张表把谁在哪个部门担任什么角色这一政企最核心的组织语义数据结构化了使整个工作流引擎能用简洁 SQL 完成复杂选人——这是多年集成经验沉淀下的工程选择而非纸上谈兵。8.3 延伸阅读组织结构数据字典与运行模式doc/组织结构.md工作流引擎整体技术白皮书doc/驰骋BPM工作流引擎技术白皮书2026版.md本文档由驰骋 BPM 技术团队基于源码分析编写转载请注明出处。
