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

一天，朱斯参加了一场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)！"