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