工作流数据模型

**本文引用的文件** - [workflow.sql](file://docs/ddl/workflow.sql) - [BaseEntity.java](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-workflow/lemes-service-dm-workflow-common/src/main/java/com/lenovo/lemes/service/dm/workflow/common/BaseEntity.java) - [FlowBusinessConfigDo.java](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-workflow/lemes-service-dm-workflow-common/src/main/java/com/lenovo/lemes/service/dm/workflow/entity/inner/FlowBusinessConfigDo.java) - [FlowNodeConfigDo.java](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-workflow/lemes-service-dm-workflow-common/src/main/java/com/lenovo/lemes/service/dm/workflow/entity/inner/FlowNodeConfigDo.java) - [FlowAuditLogDo.java](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-workflow/lemes-service-dm-workflow-common/src/main/java/com/lenovo/lemes/service/dm/workflow/entity/inner/FlowAuditLogDo.java) - [UserDO.java](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-workflow/lemes-service-dm-workflow-common/src/main/java/com/lenovo/lemes/service/dm/workflow/entity/inner/UserDO.java) - [RoleDO.java](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-workflow/lemes-service-dm-workflow-common/src/main/java/com/lenovo/lemes/service/dm/workflow/entity/inner/RoleDO.java) - [ProcessInfoResp.java](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-workflow/lemes-service-dm-workflow-common/src/main/java/com/lenovo/lemes/service/dm/workflow/entity/outer/ProcessInfoResp.java) - [ActivityDTO.java](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-workflow/lemes-service-dm-workflow-common/src/main/java/com/lenovo/lemes/service/dm/workflow/entity/dto/ActivityDTO.java) - [NextTaskDTO.java](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-workflow/lemes-service-dm-workflow-common/src/main/java/com/lenovo/lemes/service/dm/workflow/entity/dto/NextTaskDTO.java) - [ApproveProcessVO.java](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-workflow/lemes-service-dm-workflow-common/src/main/java/com/lenovo/lemes/service/dm/workflow/entity/vo/ApproveProcessVO.java)

目录

1. 简介
2. 项目结构
3. 核心组件
4. 架构总览
5. 详细组件分析
6. 依赖分析
7. 性能考虑
8. 故障排查指南
9. 结论
10. 附录

简介

本文件面向工作流系统的数据建模与使用，系统性梳理“内部实体（inner 包）”与“外部响应实体（outer 包）”的设计与职责，并阐明流程定义、任务、流程实例、用户、角色等核心实体之间的关系。文档同时总结了实体命名规范、字段设计原则、数据类型选择、索引策略等设计原则，并提供在业务逻辑中正确使用这些实体的示例与扩展指导。

项目结构

工作流数据模型主要分布在以下位置：

• DDL 定义：数据库表结构位于 docs/ddl/workflow.sql
• 内部实体（inner）：对应持久化表的 Java 实体类，位于 lemes-cloud/.../workflow/entity/inner
• 外部响应实体（outer）：对外输出或接口返回的数据结构，位于 lemes-cloud/.../workflow/entity/outer
• DTO/VO：用于业务处理与接口交互的数据传输对象，位于 lemes-cloud/.../workflow/entity/dto 与 entity/vo
• 基类：统一的 BaseEntity 位于 lemes-cloud/.../workflow/common

图表来源

• workflow.sql:111-146
• workflow.sql:276-325
• workflow.sql:198-274
• workflow.sql:327-363
• workflow.sql:365-411
• FlowBusinessConfigDo.java:1-30
• FlowNodeConfigDo.java:1-37
• FlowAuditLogDo.java:1-44
• UserDO.java:1-39
• RoleDO.java:1-62
• ProcessInfoResp.java:1-25
• ActivityDTO.java:1-25
• NextTaskDTO.java:1-31
• ApproveProcessVO.java:1-61

章节来源

• workflow.sql:1-564
• BaseEntity.java:1-16

核心组件

• 内部实体（inner）
  • 流程业务配置：FlowBusinessConfigDo，映射 flow_business_config 表，描述业务与流程图的绑定关系及节点数量。
  • 流程节点配置：FlowNodeConfigDo，映射 flow_node_config 表，描述流程图中各节点的标题、顺序、活动 ID、前置节点与类型等。
  • 审批日志：FlowAuditLogDo，映射 flow_audit_log 表，记录流程实例在各节点的审批状态、审批人、业务单据等。
  • 用户：UserDO，映射 flow_user 表，记录用户登录账号、姓名、状态等。
  • 角色：RoleDO，映射 flow_user_role 表，记录用户的角色、工厂/部门维度与层级（工厂级/部门级）。
• 外部响应实体（outer）
  • 流程信息响应：ProcessInfoResp，封装流程实例开启人、开启时间、流程定义 Key 以及历史任务实例列表。
• DTO/VO
  • 活动信息：ActivityDTO，承载流程活动 ID 与名称。
  • 下一任务：NextTaskDTO，承载下一节点的活动 ID、可选替换审批人与部门 ID。
  • 审批请求 VO：ApproveProcessVO，承载审批人、工厂、任务/流程实例、审批结果、审批意见、下一节点配置、流程变量等。

章节来源

• FlowBusinessConfigDo.java:1-30
• FlowNodeConfigDo.java:1-37
• FlowAuditLogDo.java:1-44
• UserDO.java:1-39
• RoleDO.java:1-62
• ProcessInfoResp.java:1-25
• ActivityDTO.java:1-25
• NextTaskDTO.java:1-31
• ApproveProcessVO.java:1-61

架构总览

工作流数据模型采用“DDL 映射 + Java 实体 + DTO/VO/响应”的分层设计：

• DDL 层：定义表结构、约束与注释，确保数据库层面的完整性与可维护性。
• 实体层（inner）：以 MyBatis-Plus 注解映射到具体表，统一继承 BaseEntity，便于通用字段管理。
• 传输层（dto/vo/outer）：面向接口与业务处理，封装对外输出与输入的数据结构。

图表来源

• BaseEntity.java:1-16
• FlowBusinessConfigDo.java:1-30
• FlowNodeConfigDo.java:1-37
• FlowAuditLogDo.java:1-44
• UserDO.java:1-39
• RoleDO.java:1-62
• ProcessInfoResp.java:1-25
• ActivityDTO.java:1-25
• NextTaskDTO.java:1-31
• ApproveProcessVO.java:1-61

详细组件分析

流程业务配置实体（FlowBusinessConfigDo）

• 设计要点
  • 映射 flow_business_config 表，记录业务 CODE 与流程图 KEY 的绑定关系，以及流程节点数量。
  • 使用 MyBatis-Plus 注解映射表名，统一继承 BaseEntity。
• 字段与类型
  • 主键：Long id
  • 流程图 KEY：String wfKey
  • 业务 CODE：String businessCode
  • 节点数：Integer nodeNumber
• 使用场景
  • 在启动流程时根据 businessCode 查询对应的 wfKey，决定流程图版本与节点数。

章节来源

• workflow.sql:111-146
• FlowBusinessConfigDo.java:1-30

流程节点配置实体（FlowNodeConfigDo）

• 设计要点
  • 映射 flow_node_config 表，按 wf_key 与 node_index 组合唯一，记录节点标题、活动 ID、前置节点与类型。
• 字段与类型
  • 主键：Long id
  • 流程图 KEY：String wfKey
  • 节点标题：String nodeTitle
  • 节点顺序：Integer nodeIndex
  • 活动 ID：String activityId
  • 前置节点：String preActivityId
  • 节点类型：Integer nodeType
  • 节点参数：String nodeParameters
• 使用场景
  • 在流程推进时依据当前节点与前置节点判断下一节点集合，或进行节点类型判定。

章节来源

• workflow.sql:276-325
• FlowNodeConfigDo.java:1-37

审批日志实体（FlowAuditLogDo）

• 设计要点
  • 映射 flow_audit_log 表，记录流程实例在各节点的审批状态、审批人、业务单据、任务 ID、申请时间等。
  • 继承 BaseEntity，统一管理通用字段。
• 字段与类型
  • 流程实例 ID：String processInstanceId
  • 业务 CODE：String businessCode
  • 节点标题：String nodeTitle
  • 节点序号：Integer nodeIndex
  • 审批状态：Integer auditStatus
  • 审批时间：Date auditTime
  • 审批人：String auditUser
  • 审批人 ID：String auditUserId
  • 业务单号：String businessOrderNo
  • 业务类型：Integer businessOrderType
  • 任务 ID：String taskId
  • 申请人：String applyUser
  • 申请时间：Date applyTime
  • 备注：String remark
• 使用场景
  • 审批操作完成后写入审批日志，支持审计追踪与历史查询。

章节来源

• workflow.sql:1-71
• FlowAuditLogDo.java:1-44

用户实体（UserDO）

• 设计要点
  • 映射 flow_user 表，记录用户登录账号、姓名、状态与用户 ID。
  • 继承 BaseEntity，支持统一扩展。
• 字段与类型
  • 用户 ID：String userId
  • 登录账号：String account
  • 用户名：String userName
  • 状态：Integer status
• 使用场景
  • 审批人识别、流程实例发起人识别、用户权限校验。

章节来源

• workflow.sql:327-363
• UserDO.java:1-39

角色实体（RoleDO）

• 设计要点
  • 映射 flow_user_role 表，记录用户的角色、角色层级（工厂级/部门级）、工厂与部门维度。
• 字段与类型
  • 角色 ID：Long roleId
  • 角色名称：String roleName
  • 用户 ID：String userId
  • 工厂 ID：Long factoryId
  • 部门 ID：Long departmentId
  • 创建/修改人：String createUser/updateUser
  • 层级：Integer hierarchy
• 使用场景
  • 基于用户角色与层级确定审批权限与可见范围。

章节来源

• workflow.sql:365-411
• RoleDO.java:1-62

外部响应实体（ProcessInfoResp）

• 设计要点
  • 封装流程实例的关键信息：开启人、开启时间、流程定义 Key，以及历史任务实例列表。
• 字段与类型
  • 开启人：String processInstanceStarter
  • 开启时间：String processStartTime
  • 流程定义 Key：String processDefinitionKey
  • 历史任务实例列表：List<HisTaskInstanceResp>
• 使用场景
  • 对外返回流程实例概览信息，供前端展示与后续操作。

章节来源

• ProcessInfoResp.java:1-25

DTO/VO（ActivityDTO、NextTaskDTO、ApproveProcessVO）

• ActivityDTO
  • 作用：承载流程活动 ID 与名称，用于流程活动查询与展示。
• NextTaskDTO
  • 作用：承载下一节点的活动 ID、可选替换审批人与部门 ID，用于审批时指定下一节点审批人。
• ApproveProcessVO
  • 作用：审批请求的核心载体，包含审批人、工厂、任务/流程实例、审批结果、审批意见、下一节点配置、流程变量等。

章节来源

• ActivityDTO.java:1-25
• NextTaskDTO.java:1-31
• ApproveProcessVO.java:1-61

依赖分析

• 表与实体映射
  • flow_business_config ↔ FlowBusinessConfigDo
  • flow_node_config ↔ FlowNodeConfigDo
  • flow_audit_log ↔ FlowAuditLogDo
  • flow_user ↔ UserDO
  • flow_user_role ↔ RoleDO
• 实体与传输对象的关系
  • FlowBusinessConfigDo → ProcessInfoResp（业务流程配置参与流程信息）
  • FlowNodeConfigDo → ActivityDTO（节点活动信息）
  • FlowAuditLogDo → NextTaskDTO（审批日志与下一节点配置）
  • UserDO → ApproveProcessVO（审批人信息）
  • RoleDO → ApproveProcessVO（角色/层级影响审批权限）

图表来源

• workflow.sql:111-146
• workflow.sql:276-325
• workflow.sql:1-71
• workflow.sql:327-363
• workflow.sql:365-411

性能考虑

• 索引策略建议
  • flow_business_config：按 business_code 建立唯一索引，加速业务到流程图的映射查询。
  • flow_node_config：按 (wf_key, node_index) 建立联合主键，保证节点顺序与流程图的稳定性；必要时对 activity_id 建立索引以加速节点定位。
  • flow_audit_log：按 process_instance_id、business_code、task_id 建立索引，支撑流程实例审计与任务追踪查询。
  • flow_user：按 user_id 建立唯一索引，按 account 建立索引，支撑登录与用户检索。
  • flow_user_role：按 user_id 建立索引，按 (factory_id, department_id, hierarchy) 建立复合索引，支撑按组织层级的权限查询。
• 字段设计
  • 使用整型小数位（如 smallint）表达枚举型状态与类型，减少存储与比较成本。
  • 时间字段统一使用 timestamp(6)，保证高精度与时区一致性。
• 批量与异步
  • 审批日志写入建议采用批量/异步方式，避免阻塞主流程。

故障排查指南

• 常见问题
  • 审批失败或无法推进：检查 flow_node_config 中当前节点与下一节点配置是否正确，确认 activity_id 与 node_index 的一致性。
  • 审批权限异常：核对 flow_user_role 中用户的角色层级与工厂/部门维度，确认 hierarchy 与审批范围匹配。
  • 审批记录缺失：检查 flow_audit_log 的写入路径与字段映射，确认 process_instance_id、task_id、audit_status 是否正确。
• 排查步骤
  1. 根据业务 CODE 查询 flow_business_config 获取 wf_key。
  2. 根据 wf_key 与节点序号查询 flow_node_config 获取下一节点集合。
  3. 根据流程实例 ID 查询 flow_audit_log 核对审批状态与审批人。
  4. 根据用户 ID 查询 flow_user_role 确认审批权限层级。

章节来源

• workflow.sql:111-146
• workflow.sql:276-325
• workflow.sql:1-71
• workflow.sql:365-411

结论

工作流数据模型通过 DDL 明确表结构与约束，Java 实体统一映射并继承 BaseEntity，传输对象清晰分离内部持久化与外部接口职责。该设计在可维护性、扩展性与性能之间取得平衡，适合在复杂业务场景中演进。建议在新增实体或调整关系时遵循本文的设计原则与扩展指导。

附录

设计原则与规范

• 实体命名规范
  • inner 包：以 Do 结尾，表示持久化实体；例如 FlowBusinessConfigDo、FlowNodeConfigDo。
  • outer 包：以 Resp 结尾，表示对外响应；例如 ProcessInfoResp。
  • dto/vo：以 DTO/VO 结尾，表示传输对象；例如 ActivityDTO、NextTaskDTO、ApproveProcessVO。
• 字段设计原则
  • 语义明确：字段名与注释一致，避免歧义。
  • 类型合理：枚举型使用整型小数位，时间使用 timestamp，字符串长度适配业务。
  • 可扩展：预留扩展字段（如 remark），避免频繁变更表结构。
• 数据类型选择
  • 主键：Long 或 bigserial，优先自增主键。
  • 关联键：与业务主键保持一致（如 user_id），便于跨模块关联。
• 索引策略
  • 唯一键：business_code、(wf_key, node_index)、user_id 等。
  • 查询键：process_instance_id、task_id、audit_user_id 等高频过滤字段。
• 扩展指导
  • 新增实体：先在 DDL 定义表结构与注释，再映射到 Java 实体，最后在 outer/dto/vo 中补充对外结构。
  • 修改现有实体：评估字段变更对索引与查询的影响，必要时增加兼容字段与迁移脚本。
  • 实体关系调整：通过中间表（如 flow_user_role）解耦多对多关系，保持查询与权限控制清晰。