【原創】爲何要用規則引擎？

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