业务逻辑配置化的可选技术方案

问题

在很多业务应用中，往往有很多文案及按钮的业务逻辑，很容易因为产品的策略变更而变化，或因为来了新业务而新增条件判断，或因为不同业务的差异性而有所不同。如果通过代码来实现，通常要写一串if-elseif-elseif-else语句，且后续修改扩展比较容易出错，需要重新发布，灵活性差。 可采用配置化的方法来实现按钮逻辑，从而在需要修改的时候只要变更配置即可。业务逻辑的代码形式一般是：

public Boolean getIsAllowBuyAgain() {
  if (ConditionA) {
    return BoolA;
  }
  if (ConditionB) {
    return BoolB;
  }
 
  if (CondtionC && !CondtionD && (ConditionE not in [v1,v2])) {
    return BoolC;
  }
  return BoolD;
}

本文讨论了三种可选方案： 重量级的Groovy脚本方案、轻量级的规则引擎方案、超轻量级的条件匹配表达式方案。

方案

Groovy脚本

需要在界面上进行编辑和及时刷新到应用中的代码，可以使用 Groovy 脚本来替代。

可参阅：“使用yaml+groovy实现Java代码可配置化”

规则引擎

多样化可变的业务逻辑和规则集合非常相似，可以考虑采用一款轻量级的规则引擎。通过配置平台来管理规则集合。

使用规则引擎的示例可参阅： “Java Drools5.1 规则流基础【示例】（上）”

可选用一款轻量级的Java开源规则引擎作为起点。

条件表达式

对于轻量级判断逻辑，采用条件表达匹配。条件表达匹配，实质是规则引擎的超轻量级实现。

条件表达式方案可参阅：“详情文案的轻量级表达式配置方案”

选择

三种方案的对比如下：

方案	灵活性	性能	易懂性	适用场景
Groovy 脚本	极高，凡是代码解决都能用Groovy脚本解决	需要缓存，几十到几百毫秒	业务人员不易读懂	代码配置化，方便技术人员使用
规则引擎	较高	几十毫秒	适合业务人员读懂	大量规则和推理，规则之间有关联
条件表达式	特定	几到几十毫秒	适合业务人员读懂	少量复合条件，相互独立