通用流程建模

目录

• 背景和价值
• 流程矩阵编排
  • • 业务活动（华为流程框架的L5）
    • 任务
    • 步骤
• 技巧总结
  • 步骤设计技巧
  • 案例
  • 步骤的扩展点的多种实现模式
  • 风险
• 参考资料

背景和价值

订单评审业务活动的业务规则非常复杂，

数十个业务场景，有不同的业务规则差异。

• 自动评审，手动评审
• 整单评审，按行评审（这个不讲）
• 计税差异，全球不同国家税则不一样
• 分货占用： IOT，零售物料，贸易合规不需要占用。大货占用
• 额度占用： 新架构都要占用，老架构MTO 发货前3天使用承诺行占用
• 推送履约系统：ofp，eam，eco

流程矩阵编排

业务活动（华为流程框架的L5）

任务

步骤

技巧总结

步骤设计技巧

• 步骤是最小可编排的业务规则单元。步骤是解决不同场景有或者没有的业务规则组件的问题，从技术角度来看编排要比规则的逻辑判断更简单。 步骤的扩展点，是解决不同的业务场景规则的实现差异。
• 如果同一个步骤，不同业务场景在细粒度的规则有 存在，和不存在的差异，那么需要把步骤进一步拆细，实现可编排的目的。如果步骤太粗，规则实现会很复杂，影响扩展。

案例

如订单评审L5的校验逻辑有：客户是否正常合作，购销关系是否存在。

--

业务场景	客户状态校验	购销关系校验
贸易合规	N	N
中国区_大货	Y	Y
欧洲_大货	Y	N

如果订单评审的校验封装一个步骤会发现代码难以扩展，伪代码

if   '客户状态校验'
   if '贸易合规' None
   if '中国区_大货' || '欧洲_大货'  then xxx
if   '购销关系校验'
   if '贸易合规' None
   if '中国区_大货' then xxx
   if '欧洲_大货' then xxx

代码实现。 一个是空类，一个是客户校验类。不同的场景路由到不同的类执行。

这个时候如果新增新的场景，扩展不是那么容易实现。 所以需要进一步把步骤拆细。 拆成客户校验 和 购销关系校验2个步骤。那么代码扩展就简单多了
客户状态校验步骤的代码

  通用规则

购销关系校验校验步骤的代码

 通用规则

贸易合规没有客户状态校验 ， 购销关系校验在步骤编排的时候，不包含这2个步骤即可。 欧洲_大货场景也是类似

步骤的扩展点的多种实现模式

1 策略。 不同的场景走不通的策略。 策略模式
2 所有场景都走通过的逻辑，不同的场景再细分不同的规则。模板方法设计模式
比如客户是否存在校验，不同的场景有不同的规则差异，可以参考以上两种模式。

风险

通过业务变量识别场景编码，有可能在订单的过程中场景编码可能会发生变化，比如 下单的过程中客户类型发生了变化，导致场景编码的变化，但是进入下单的流程过程中
场景编码是静态传进去的，但是在代码执行过程中，场景编码变了，导致 配置表的逻辑路由出错。

参考资料