1， 多變業務
開發系統時，有沒有試過下面的情況，如果你試過，那可以考慮一下使用規則引擎了。
序號
問題
舉例
1
業務規則來自於一個或多個表格
商店的會員積分表，停車場的計費標准，快遞費的計算表，客戶信用評分表
2
業務規則是客戶自己寫的，難以結構化。
工資計算辦法，生產配方計算，保險計算，公式系統。
業務規則來自於表格，一般情況下表格有多個列，而這些列之間有條件和結果關系。如：
積分
會員等級
打折
0-100
普通會員
--
100-1000
白銀會員
0.99
1000-5000
黃金會員
0.9
5000~
VIP
0.85
這三列中，積分和會員等級就是條件，而打折往往就是結果，通常都是通過條件找到結果，上述表格可以用數據表保存起來，但這個做法真不提倡，上表也許是用戶隨手搞的，可能過一兩個月就會變。
這些基於表格的規則，可以理解為結構化的規則。
但用戶常常都會有非結構化的規則要求軟件公司實現的，如上表，客戶增加如下要求：A，入黑名單的會員不打折，B，3月8日婦女節，女會員折上折98，C，商品X不參與打折。
那就不是表格式的規則了，可以理解為非結構化的規則。
事實上，非結構化的規則，簡直就是用戶隨手編寫的公式，也許很多會員系統已經處理了這些問題，但對於小開發團隊或行業經驗還不夠豐富的團隊來說，上面的要求就是“變態”，因為自己實現不了。
2，規則引擎
規則引擎就是為了處理復雜多變的業務而出現的，而把這些變化封裝到規則引擎中，提供通用的接口，讓實施人員或客戶在不改變低層代碼的前提下，可以比較簡單地改變規則。
CKRule規則引擎並不是使用rete算法實現的，而是使用編譯，即規則都是代碼來實現，基於.Net4.0的C#語言編寫的。
上面的問題，規則引擎都處理得非常好。對於表格式的數據，可定義決策表進行處理，對於非結構化的規則，就直接編寫公式來處理。對表格式數據，需要先標出條件列和結論列，引擎掃描每一行數據，用條件列來判斷條件是否正確，如果成立就執行結論列的數據。
而針對非結構化的規則，開發員可以在引擎中定義非常簡化的關鍵字，對比邏輯和結論操作。並在業務系統調用這些定義，開發出適合當前業務系統的界面，提供友好，簡單的公式編輯。在CKRule中，非結構化規則被稱為客戶規則池，其架構圖如下：
從上圖中，可以清楚看到，終端用戶始終在業務系統上面操作非結構化的公式編輯，和測試編寫的公式，保存之後被放在數據庫中，終端用戶是不需要與引擎直接接觸的，這一特點就是強大的客戶規則池功能。
即使你遇到再無厘頭的業務規則要求，都可以在引擎中編輯好基礎的元數據，然後在你的業務系統中編輯公式。這些公式是使用C#編譯的，你可以非常簡單地改變任何業務規則。如果開發員定義的關鍵字，比較邏輯和結論邏輯足夠完善或客戶公式足夠簡單，那把客戶規則完全交給客戶來編寫，是絕對可行而且非常節約成本的事。
想了解CKRule的體系結構，案例和下載應用，請查看：
http://www.ckrule.com/
