我在項目中一直使用JBoss Drools 這個開源的規則驅動引擎， 為什么要用它？ 我要想出個一二三來說服別人。
對于business rule, 一般的情況是， 好的BA，可能更善于發現、抽取business rule ，并用結構化的方式描述、記錄下來， 普通的BA可能更是一種流水賬式的、吃那拉那的描述方式。
不管怎樣，BA在寫文檔，use case的時候，那些business rule被分布在文檔中不同的部分，然后這些rule，在分工時，有被理所當然的分給不同的開發人員來開發。
好的開發人員會刻意的使用各種手段剝分離、封裝、結構化他們，并積極的重構他們，以防止規則的變化，沖擊到設計或代碼的結構。
而普通的開發人員則極有可能硬編碼寫死在代碼當中，完成coding 任務，草草了事。
可以看出，這種方式，隨意性太大，不可控的風險也隨之增大。后果是，開發人員總是抱怨需求的變更，殊不知，合理的設計手段，在一定程度上，可以緩沖需求的變化。
JBoss Drools, 它在一定程度上解決了上面的問題：
1）規則首先應當是可管理的
?? 規則是相對靈活、復雜的，我們要控制、管理它們，而不是直接暴露給開發人員，愿意怎么搞，就怎么搞，一個人一種style。
?? Drools使用script，將rule集中寫在規則庫文件當中， 使得設計人員更容易管理。同時可以設計復雜的業務規則，并在沒有編寫任何代碼的情況下自動綁定企業數據。提供帶有菜單提示和下拉列表的向導來幫助用戶完成設計過程。
2）我們則設計是，總要遵循一些原則：
?? 將易變的和不變的分離出來
?? 封裝可變的規則， 避免硬編碼編程
?? 將多源的規則，合并、整理成單源的規則，一進一出，降低復雜度。
?? Drools將規則寫在配置文件當中，以集中強制的方式剝離了規則，而不是寫死在代碼當中。在規則變化而修改腳本文件時，不用重新部署系統。
3）規則應當使用一種清晰、易懂的方式記錄下來，并明確下來，無論是漢語還是英文句子，都不是表達規則的好的方式。大段大段的文字，往往讓人發暈。
?? 偽代碼、script語言反而時表達規則的一種極好的方式， 結構化的表達方式，讓開發人員覺得非常親切，更加平易近人。
?? Drools 引入了更為強大且的業務行為腳本語言（MVFlex表達式語言）。用戶會發現腳本語言的引入使得代碼變得更為簡明且可讀性更好。