前篇隨筆《需求收集、分析》中簡單提了一下業務規則。業務規則是很重要的一個東西，并且用戶對于業務規則也極易
更改或者新增新的業務規則.尤其是在某些場合如促銷，積分商城等場景。正因為規則如此重要，建議使用單獨的文檔
維護，規則名稱編號可以與用例名稱編對一一對應。
業務規則分類：
一,內稟規則：業務實體本身的規則。如訂單中銷售記錄不能為空，數量不能為等。
二，全局規則：一般與所有用例相關而不是某個特定用例相關。例如系統安全方面的sql注入，ddos攻擊等。
三，交互規則：用于用例當中。
它們規定了滿足什么條件后業務將如何反應。有些規則需要開發成系統用例。比如人事
管理系統中請假業務只有工作日才計入請假天數，那么這個工作日就需要電腦來維護了，會作為一個系統用例存在，并
且作為請假用例的前置條件。 交互規則又是最容易引起.
交互規則如此靈活多變，需要良好的設計才能保證系統的擴展性和可維護性。如何做：
思路一：
在 javax.swing.border包提供了Border接口和幾個不同的Boder的實現。在swing中每個組件提供了paint方法，每
個組件知道怎么畫自己展示自己的外觀。那么我們可以提供業務規則處理接口，每個具體業務規則自己知道怎么處理業務。
可以用簡單工廠來決定調用哪一個具體業務規則。這個是策略模式的使用,缺點是新增具體業務時工廠類會修改。也可以
用觀察者模式來實現，所有的具體業務類都來觀察這個業務規則，自己判斷是不是自己可以處理的，不是就不理會。
基于策略模式的規則實現類圖:
思路二：
規則引擎比如drools處理一些問題 。規則引擎適合于做業務規則頻繁變化的場景.把業務規則抽出來通過規則引擎來
處理。類似工作流系統的概念。
自定義規則處理庫:
一些動態的語言很適合來做這樣的事情。java支持script.Mvel是一個表達式語言，drools也支持mvel來處理業務規則.
這里自定義規則引擎使用Mvel表達式語言.
規則文件示例：
<rules>
<!--rule-set 是一個規則集,執行規則 rule1時會迭代規則集里面所有的規則(mvel-rule)-->
<rule-set name="rule1">
<!-- id是規則的標識，也是默認的排序處理順序。exclusive 是排它。如果為true,則當前規則執行后，不再執行后面的規則-->
<mvel-rule id="step1" exclusive="false">
<block><![CDATA[
if(salary<=3500) {result=0;}
]]></block>
</mvel-rule>
<mvel-rule id="step2" exclusive="false">
<block><![CDATA[if(salary>3500) {result=1};]]></block>
</mvel-rule>
</rule-set>
<rule-set name="rule2">
<mvel-rule id="step1" exclusive="false">
<block><![CDATA[
import com.custom.rule.*;
rs = new RuleSet();
rs.name="asdf";
rs.print();
]]></block>
</mvel-rule>
</rule-set>
</rules>
rule2中可見mvel可以導入未知jar包并進行處理，確實強大，就有了足夠的靈活性.
自定義規則庫源碼及使用示例下載.
本例依賴xstream1.4.9 ,mvel2.0
自定義規則庫除了可以應用于一般系統業務處理，當然也還可以用于大數據處理。比如hadoop/spark統計用戶積分等
如果再定義一套配置規則的UI。。。好的，業務人員可以自己設置計算規則了。