背景

在年底，突发奇想，想对公司内部现有的菜单权限进行重新设计。

观察了令人头疼的硬编码后，想出可用规则引擎进行重构。

分析

观察如下代码，硬编码，很临时，很敷衍。但其实用数学或者代数思维理解，就是「取代」。

      if (system.contains(1109) && control.contains(1126)) {
        control.remove(1126);
      }
      if (system.contains(1109) && control.contains(1143)) {
        control.remove(1143);
      }
      if (system.contains(1113) && control.contains(1127)) {
        control.remove(1127);
      }

设计

观察了各种硬编码模式，分析了背后的意图，便总结出来一些范式。

业务范式

「业务范式」是我自己取的概念，也可以用计算机的思维理解，叫做 「关系运算指令」也可以。

例如：

• 是否是公共基础菜单
• 取代
• 管理员必须有
• 管理员不应有
• XX角色应该有
• XX类型用户应该有
• 离职中用户应该有
• 在职用户不应该有
• 普通用户不应该有
• 其他罕见类型

其实都是人类思维。硬生生写成了代码。现在的过程就是反过来按照人类思维总结设计。

规则引擎

以前模模糊糊了解过规则引擎，但这次突然想明白了。

规则引擎定义

规则引擎是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

规则本质上是一个函数，如y=f(x1,x2,..,xn)

规则引擎由三部分

事实（Fact）：就是用户输入的已经事实，可以理解为推理前的已知对象。
LHS(Left Hand Side)：可以理解为规则执行需要满足的条件。
RHS(Right Hand Sike)：可以理解为规则执行后的返回对象。

理解反思

那么以上的业务范式就隐含了规则引擎的三个部分。

以「取代」为例：
当什么模块下，什么菜单，应该优先于（取代）什么菜单。

事实：模块，或者出现了某个已知的，要被菜单
LHS：执行满足条件，这个条件比较简单，就是假设出现了这个菜单，或者是假设用户是某个角色，有点像邮件整理规则。
RHS: 执行后返回对象，这个就是用什么菜单 去取代之前的菜单。

这个又有点像运算符，或者指令集。

应用

在这个业务场景下，目标非常清晰和简单，就是将原本的编程代码逻辑，反向改成规则描述的通俗易懂的逻辑。

好在这个业务范式足够简单，甚至没有加减乘除。

如果需要一些判断条件，则需要具体对LHS进行设计。