BPMN 基础建模

1. 什么是流程建模（Process Modeling）

所谓“流程建模”，就是把人类世界的业务步骤，用一种标准化、可执行的图形语言表达出来。
这个过程的目标，是让系统理解“谁在什么时候做什么事，满足什么条件后进入下一步”。

建模并不是在画“好看”的流程图，而是在构建一个逻辑可执行的过程模型。
流程引擎正是通过解析这个模型来控制系统行为的。

因此，建模 = 把业务逻辑抽象成模型，让机器能执行。

2. BPMN 建模的基本流程

建模通常分为以下几个阶段：

理解业务场景：先明确业务目标、参与者、操作步骤。
抽象流程角色：确定谁参与了这个流程。
定义关键活动：梳理各个环节对应的操作或审批节点。
设置事件与条件：明确流程何时开始、何时结束、如何分支。
优化与验证：检查逻辑是否闭合，是否存在死循环或遗漏。
部署执行：将 BPMN 文件导入引擎，启动流程实例。

接下来，我们用一个完整的例子贯穿说明。

3. 建模实战

我们选择最经典的例子——员工请假流程。
这类流程清晰、层次分明，非常适合初学者理解 BPMN 的核心概念。

3.1. 业务背景

公司规定：

员工填写请假单提交申请；
如果请假天数 ≤ 3 天，由直属主管审批；
如果请假天数 > 3 天，则需总经理审批；
审批通过后，HR 备案流程结束。

3.2. 确定参与角色（泳道）

我们识别出四个参与者：

员工：发起申请。
主管：审批 3 天以内的请假。
总经理：审批超过 3 天的请假。
HR：进行备案。

因此，我们可以在流程设计器中创建一个泳池（Pool）表示整个公司，
再划分四条泳道（Lane），分别对应这四个角色。

3.3. 定义流程结构

流程的主要节点如下：

开始事件：流程启动（员工提交申请）。
用户任务：填写请假单（Employee）。
排他网关：判断天数是否大于 3 天。
用户任务：主管审批（Manager）。
用户任务：总经理审批（Director）。
用户任务：HR 备案。
结束事件。

3.4. 建立流程走向

接下来，我们用箭头（顺序流）连接这些节点：

[开始]
   ↓
[员工填写请假单]
   ↓
<排他网关：天数>3？>
   ↙                 ↘
[主管审批]       [总经理审批]
   ↘                 ↙
       [HR 备案]
          ↓
         [结束]

这时，一张逻辑完整的 BPMN 模型就形成了。

3.5. 添加条件与变量

在排他网关处，我们需要定义条件表达式：

<sequenceFlow id="flow1" sourceRef="gateway1" targetRef="managerTask">
    <conditionExpression xsi:type="tFormalExpression">${days <= 3}</conditionExpression>
</sequenceFlow>
<sequenceFlow id="flow2" sourceRef="gateway1" targetRef="directorTask">
    <conditionExpression xsi:type="tFormalExpression">${days > 3}</conditionExpression>
</sequenceFlow>

这里的 days 是流程变量（Process Variable），
代表员工请假天数，它的值在“填写请假单”节点中由用户输入。

引擎在运行时会根据 days 的取值判断流程该走哪条路径。

3.6. 设置任务执行人

每个用户任务（User Task）都需要指定负责人。
可以是固定人员，也可以根据流程变量动态指定。

例如：

<userTask id="task_manager" name="主管审批" flowable:assignee="${manager}"/>
<userTask id="task_director" name="总经理审批" flowable:assignee="${director}"/>

这表示：

在流程启动时，系统会从变量中读取 manager、director，分配给对应人员；
如果审批人是固定的，也可以直接写用户名或角色。

3.7. 绑定表单或界面

在实际系统中，用户任务通常会绑定一个表单页面，例如：

“请假申请单”
“审批表单”
“备案登记表”

在 Flowable 中，可以在任务节点属性里设置 formKey：

<userTask id="applyTask" name="填写请假单" flowable:formKey="leaveForm"/>

当流程运行到此节点时，前端系统根据 formKey 渲染对应的页面。

3.8. 部署与验证

绘制完成后，将流程图保存为 .bpmn 文件，上传或部署到流程引擎中。
在 Flowable 的 UI 中，你可以：

打开 Modeler，导入文件；
点击“部署”按钮；
在 Process Instance 页面启动流程；
按顺序完成审批。

这时，你会看到任务在不同审批人之间自动流转，条件判断自动生效，整个过程完全符合流程图的定义。

4. 常见建模错误与优化

在初学阶段，建模最容易犯的错误主要有以下几类：

错误类型	原因	解决方案
忘记结束事件	流程没有终点，引擎无法结束	每个流程必须有至少一个结束事件
分支条件不全	排他网关的条件覆盖不完整	添加默认流（default flow）
孤立节点	某个节点没有输入或输出连接	确保所有节点通过顺序流相连
并行网关未汇合	并行分支未在后续汇聚	为并行网关设置对应的汇合网关
变量未定义	条件引用了不存在的变量	在前一任务中创建或初始化变量

此外，建模时应遵循“简洁、清晰、闭环”三原则：

流程应尽量短，节点过多会增加维护难度；
每个节点只负责一件事；
确保流程始终能到达结束事件。

5. 可重用与子流程

在实际系统中，一个大流程往往会复用某些小模块。
例如“审批环节”这一模式可能被多个业务复用。
BPMN 提供两种方式实现复用：

嵌入式子流程（SubProcess）：作为主流程的一部分；
调用活动（CallActivity）：直接调用外部独立流程。

这样，你可以把“通用审批流程”设计成一个单独的 .bpmn 文件，在其他流程中直接引用，极大提高了复用性。

6. 从代码逻辑到流程逻辑

许多开发者在初学 BPMN 时最大的难点在于：他们习惯了 if/else 的思维。
而 BPMN 的本质是“状态机”——每个节点代表一种状态，每条线代表一种状态转移。

举个简单的对比：

传统代码逻辑	BPMN 流程逻辑
if (days <= 3) manager.approve(); else director.approve();	排他网关（Exclusive Gateway）
while(未审批) 等待;	用户任务（User Task）
调用API(); 等待回调;	服务任务 + 接收事件（Service + Receive）

掌握这种“流程化思维”，你就能自然地把业务规则转换为 BPMN 图，而不用纠结代码实现。 business_type_tfba