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