一天，朱斯參加了一場<code>code Review</code>研讨會。會上的一群人正在讨論着如何對祖傳代碼進行變更，大家你一言，我一語,場面十分熱鬧！
突然，隻見人群中的一個人滿面愁容，說道:"昨天在項目中看到下面這樣一段代碼，分支太多了！維護起來很煩啊！"
研讨會上的另一個人提道:"這個容易啊，可以用政策模式來簡化<code>if else</code>的結構！畢竟政策模式強調的就是資料與業務邏輯分離，針對每一個分支寫一個政策就好啦！"
可是，旁邊的一個人說道:"用政策模式來簡化<code>if else</code>的代碼結構固然可以，但是這裡有一個前提，就是分支比較少，一般就十來個分支差不多了，可以用政策模式來簡化！但是如果我有上萬個分支呢？你難道做上萬個政策?就算這幾萬個政策真給你寫出來了，你以後怎麼維護？以後要修改政策，改完再重新部署一次麼？太不靈活了啊！"
此時，剛好有一位DBA大神也參加了這場<code>code Review</code>研讨會！他說道:"要不考慮一下存儲過程？将變化的政策放在存儲過程裡維護，這樣至少修改了政策，不用部署原來的應用！"
聽到這裡，朱斯實在聽不下去了，猛的回了一句:"不行！不行！用存儲過程可讀性更差，而且性能還不好！更可怕的是，如果你用的是MySQL，調試存儲過程是會要人命的！"
"唉，這也不行，那也不行，究竟該怎麼辦？"人群中充斥着吵鬧聲！
朱斯擺了擺手,示意大家靜靜，說道:"我們需要明白現在的需求是什麼？
第一，我們要簡化<code>if else</code>結構,讓業務邏輯和資料分離！
第二，分離出的業務邏輯必須要易于編寫，至少單獨編寫這些業務邏輯，要比寫代碼快！
第三，分離出的業務邏輯必須要比原來的代碼更容易讀懂！
第四，分離出的業務邏輯必須比原來的易于維護，至少改動這些邏輯，應用程式不用重新開機！
大概，就上面四點吧！"
大家問道"有滿足這樣需求的中間件麼？"
朱斯說道:"有的！那就是規則引擎!在一些強大的規則引擎中，可以像下面這樣優化，使資料和邏輯分離！"
朱斯補充道:"像上面這張圖這樣，我們将業務邏輯抽取到單獨的規則檔案裡進行維護，實作了業務和資料分離！至于資料如何傳入規則引擎呢，注意看代碼裡有一句叫<code>kieSession.insert("星期一")</code>，這樣規則引擎就知道自己有一個字元串内容為<code>星期一</code>的入參！而且，大家注意看哦，規則檔案内容是可以用中文編寫的！"
"哇塞、還能用中文來表述業務邏輯！這樣非技術人員也能看得懂呀！"人群中傳來一陣驚歎聲！
(ps:筆者的同僚，當年第一次見到我寫的中文業務邏輯，他一臉的神奇！~)
朱斯補充道:"不僅如此，當你新加一個條件分支的時候，直接新增一個規則檔案就好啦！例如，我們要多加一個判斷周二要去shopping！那我們就在規則包中新增一個檔案，内容如下!"
"大家看，我們在規則包中新增上述規則檔案後，你隻要讓你的應用程式從新加載一次規則包就好啦！完全不用重新開機原來的應用程式！"朱斯說完話，面帶笑容的看着大家。
衆人看着朱斯的講解，紛紛稱奇！
突然，人群中一陣沸騰，問道"哇哇哇，真是太神奇了，快告訴我們這套規則引擎叫啥！"
"我叫朱斯(Drools)，剛才展示的那套規則語言是我的領域特殊語言(DSL)！"
作者：孤獨煙
出處： http://rjzheng.cnblogs.com/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。如果覺得還有幫助的話，可以點一下右下角的【推薦】。