问题###
在很多业务应用中，往往有很多文案及按钮的业务逻辑，很容易因为产品的策略变更而变化，或因为来了新业务而新增条件判断，或因为不同业务的差异性而有所不同。如果通过代码来实现，通常要写一串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脚本解决 | 需要缓存，几十到几百毫秒 | 业务人员不易读懂 | 代码配置化，方便技术人员使用 |
| 规则引擎 | 较高 | 几十毫秒 | 适合业务人员读懂 | 大量规则和推理，规则之间有关联 |
| 条件表达式 | 特定 | 几到几十毫秒 | 适合业务人员读懂 | 少量复合条件，相互独立 |