【原创】为什么要用规则引擎？

一天，朱斯参加了一场code Review研讨会。会上的一群人正在讨论着如何对祖传代码进行变更，大家你一言，我一语,场面十分热闹！

突然，只见人群中的一个人满面愁容，说道:"昨天在项目中看到下面这样一段代码，分支太多了！维护起来很烦啊！"

if(day == "周一"){
  System.out.println("I will play basketball");
}else if (day == "周二"){
  System.out.println("I will do shopping");
}else if (day == "周三"){
  System.out.println("I will wash clothes");
}else if(...) {
    ...
}//很烦,写不下去了

研讨会上的另一个人提道:"这个容易啊，可以用策略模式来简化if else的结构！毕竟策略模式强调的就是数据与业务逻辑分离，针对每一个分支写一个策略就好啦！"

可是，旁边的一个人说道:"用策略模式来简化if else的代码结构固然可以，但是这里有一个前提，就是分支比较少，一般就十来个分支差不多了，可以用策略模式来简化！但是如果我有上万个分支呢？你难道做上万个策略?就算这几万个策略真给你写出来了，你以后怎么维护？以后要修改策略，改完再重新部署一次么？太不灵活了啊！"

此时，刚好有一位DBA大神也参加了这场code Review研讨会！他说道:"要不考虑一下存储过程？将变化的策略放在存储过程里维护，这样至少修改了策略，不用部署原来的应用！"

听到这里，朱斯实在听不下去了，猛的回了一句:"不行！不行！用存储过程可读性更差，而且性能还不好！更可怕的是，如果你用的是MySQL，调试存储过程是会要人命的！"

"唉，这也不行，那也不行，究竟该怎么办？"人群中充斥着吵闹声！

朱斯摆了摆手,示意大家静静，说道:"我们需要明白现在的需求是什么？

• 第一，我们要简化if else结构,让业务逻辑和数据分离！
• 第二，分离出的业务逻辑必须要易于编写，至少单独编写这些业务逻辑，要比写代码快！
• 第三，分离出的业务逻辑必须要比原来的代码更容易读懂！
• 第四，分离出的业务逻辑必须比原来的易于维护，至少改动这些逻辑，应用程序不用重启！
  大概，就上面四点吧！"

大家问道"有满足这样需求的中间件么？"

朱斯说道:"有的！那就是规则引擎!在一些强大的规则引擎中，可以像下面这样优化，使数据和逻辑分离！"

朱斯补充道:"像上面这张图这样，我们将业务逻辑抽取到单独的规则文件里进行维护，实现了业务和数据分离！至于数据如何传入规则引擎呢，注意看代码里有一句叫kieSession.insert("星期一")，这样规则引擎就知道自己有一个字符串内容为星期一的入参！而且，大家注意看哦，规则文件内容是可以用中文编写的！"

"哇塞、还能用中文来表述业务逻辑！这样非技术人员也能看得懂呀！"人群中传来一阵惊叹声！
(ps:笔者的同事，当年第一次见到我写的中文业务逻辑，他一脸的神奇！~)

朱斯补充道:"不仅如此，当你新加一个条件分支的时候，直接新增一个规则文件就好啦！例如，我们要多加一个判断周二要去shopping！那我们就在规则包中新增一个文件，内容如下!"

rule "test92"
    when
        如果今天是星期二
    then
        我要去购物  
end

"大家看，我们在规则包中新增上述规则文件后，你只要让你的应用程序从新加载一次规则包就好啦！完全不用重启原来的应用程序！"朱斯说完话，面带笑容的看着大家。

众人看着朱斯的讲解，纷纷称奇！

突然，人群中一阵沸腾，问道"哇哇哇，真是太神奇了，快告诉我们这套规则引擎叫啥！"

"我叫朱斯(Drools)，刚才展示的那套规则语言是我的领域特殊语言(DSL)！"