BPMN最佳实践:命名约定

BPMN 2.0规范没有正式的命名规范，这里是普遍公认的最佳实践和我个人积累的一些经验。

​

通用规则

  • 命名尽量简短。

    在不影响理解和造成混淆的前提下，命名越短越好，BPMN2.0主要是以设计图的形式存在，要在固定大小的组件内部写很多文字本身就是非常不美观的，也会潜在增加图的”复杂度“，越复杂就越难被理解。

    当然这需要对建模有一定的经验以及对所用语言要有强大的“炼字”能力，是需要长期积累和训练的”软实力“。

​

  • 不要使用罕见的缩写。

    杜绝完全不规范的缩写，避免望文不知义。比如：我们会用“下发入职手续清单”，而不是“下发入职手续BOM”（bill of meterial）。

    也不要因噎废食，不敢使用缩写，比较常见的缩写或者结合流程上下文环境可以容易猜到的缩写，还是可以使用的，比如“采购PC”，没有必要写成“采购Personal Computer”。

​

  • 不要使用BPMN元素类型。

    比如：我们会用“打包商品”，而不是“打包商品用户任务”或“打包商品脚本任务”。BPMN符号就是为此而设计的，这些符号完全可以做到见图知义。

​

  • 使用对业务有意义的名字。

    即使不去咨询流程的设计者也可以通过名字就大致了解业务的含义，比如：我们会用“经理审批”、“助理审批”、“计算所得税”，而不是使用“一级审批”、“二级审批”、“所得税”这样的名称。

    同样的，基于流程上下文环境，一个名词可能比另一个名词更合适，比如，我们现在正设计一个在线购物流程：我们会用“审核订单”，而不是用“审核采购项”，意思其实差不多，但是前者明显更适合这个业务场景。

​

活动

  • 所有的活动都应该命名。

​

  • 不要用同一个名字为多个活动命名（子流程活动除外）。

​

  • 在命名任务时，我们尝试去遵循面向对象的设计原则，使用[动词] + [对象]这样的模式进行命名。

    没有必要用形容词、副词等去修饰，言简意赅即可。比如：我们会用”acquire groceries“（采购食品），而不是“first take care of shopping for groceries”（首先去关注购买食品）。针对中文环境，动宾短语常常会出现宾语前置的情况，本条命名建议并不是不强制的，审核订单和订单审核其实都可以。

​

事件

  • 所有事件都应该命名。

​

  • 我们常将事件分成两类：如果是捕获事件，表示的就是已经发生的一些事情（很好理解，要捕获的一定是已经发生的事件，不管这些事情是如何处理的）；如果是抛出事件，表示的就是处理的结果。因此，无论是哪种事件，抛出事件或捕获事件，其实都代表的是一种过去时，是一种被动语态。出于这样的原因，我们使用[对象] + [动词]被动形式进行命名，比如：我们会用“hunger noticed”（感到饥饿），而不使用”hunger notice“。

​

  • Timer类型的事件根据具体类型，用Timer的定义时间计划进行命名。
    • 比如：固定的时间日期（Date）就直接命名为“2020-01-21 11:17:00“。
    • 比如：间隔一段时间（Duration）就命名为”60分钟后”、“等待3天”。
    • 比如：周期重复（Cycle）就命名为“每隔7天”。

​

  • 使用结束状态命名结束事件。

    结束事件表示做完了一件事情，因此用一些代表结束状态的词（像“结束”、“完结”、“完成”、“完毕”、“中止”、“停止”）来修饰动作，比如：”发货完成“或”采购结束“。

​

网关

  • 汇聚网关不需要命名。

    在使用并行网关、包容网关的时候经常会存在需要等待所有分支或部分分支进行汇聚或同步的情况，通常这种网关的作用显而易见，即使命名也可能只是用“汇聚”这样的命名。但是当汇聚网关逻辑不明显时，可以使用BPMN的注释对象进行说明。

​

  • 排他网关拆分出分支时，使用简短的动名词进行命名。

    比如：“判断请假天数”或“检查库存”。

​

顺序流

  • 从网关引出的连线，使用网关进行判断的条件进行命名。

    比如：“通过”、“驳回”、“同意”、“拒绝”等。

​

  • 不需要为默认顺序流进行命名。

    “如无必要，勿增实体”。将一条顺序流连线设置为“Default Flow”时，如果这条线是从网关引出的，说明当网关判断的所有条件都不满足时，就会走这条路径（有点像if-else if-else if-else这样的条件判断），那么这条线上写什么就不重要了，写一个”默认“也是多余的；如果这条线不是网关引出的，那就更不需要命名了，因为它表示的就是只有这条路径可走。

​

  • 切合环境语义。

    在实际设计、建模流程的时候，常用排它网关去表示非此即彼的二选一判断，排它网关引出的2条顺序流命名最好在语义层面是对仗工整的反义词或短语。比如：如果网关判断的条件是领导是否同意，那么顺序流命名应该是“同意”和“拒绝”，或“同意”和“不同意”，而不应该是“同意”和“驳回”，因为“驳回”通常是和“通过”一起使用的。

    顺便提一下，建议不要将这种实现二选一的排它网关后面的2条连线设置为“Default Flow”，使用一个布尔类型的必填变量是比较好的方式，要么true要么false。

​

泳道

  • 在一个泳池中不同泳道使用同一维度的名词来命名。

    使用代表角色、组织机构的名词来命名，从命名的角度讲这很简单，但是按什么样的维度来分类是考验是设计流程、划分业务的能力。

    比如可以使用角色来命名：“后勤经理”、“店员”、“仓库工人”。或使用按组织机构命名：“市场部”，“业务部”，“人力资源部”或者“售前组”，“售后组”。

    但是不要用“市场部”、“系统管理员”、“准备阶段”去命名同一池内的不同泳道。如果你发现你的流程是这样命令的，就得考虑一下是不是流程设计的有不合理的地方。

​

参考

​

EOF