在一個系統中業務規則占據了相當大的比例，而且是變動最為頻繁的，我們總是希望把容易變動的和不容易變動的分離開來，這樣就不至於因為修改易變的部分影響不需變的部分，從而簡化系統修改的復雜性，也提高系統的靈活性。
在一個系統中我們把組成部分拆分為數據，邏輯，界面等幾個部分，其中數據又可以進一步拆分為水平和垂直部分，對於邏輯絕大部分是”如果-那么”這種形式，對於界面部分可拆分為頁面，控件（文本框，下拉框，日期，文件，圖片，單選框，多選框等）和展示權限（可看，可編輯）。
業務邏輯從本質上來講就是一種規則的集合，數據和展示都是規則實施的對象，規則甚至也可以對規則起作用，這樣就成了規則的規則。因此如果要設計規則引擎那么這個規則必須要可以引用和操作數據（水平，垂直），頁面，控件，規則等組成部分。
上面也提到規則大部分是“如果-那么”這種形式，這種形式從本質上講可以看做“條件-執行”，這樣所有的規則都拆分為規則條件和規則執行體兩部分。規則有作用域，順序，黑名單，白名單，例外等。
對於規則的形式我想到了幾個簡單的例子：
- 當客戶生日時產品折扣為0.8
rule "1":
if
[Customer].[Birthday]=[Today]
then
[Product].[Rate]=0.8
else
[Product].[Rate]=1
end
- 在2013-11-01到2013-11-10期間產品貨號73022101折扣0.8
rule "2":
if
[Today]>=[2013-11-01] and [Today]<=[2013-11-10] and [Product].[sCode]=73022101
then
[Product].[Rate]=0.8
else
[Product].[Rate]=1
- 操作員級別為3的執行規則1，其他的執行規則2
rule "3":
If
[Operator].[level]=3
Then
[Rule “1”].Active=true
[Rule “2”].Active=false
Else
[Rule “1”].Active=false
[Rule “2”].Active=true
End
- 員工類型為采購時入庫價可見，其他用戶不可見
rule "4":
If
[Operator].[type]=”采購”
Then
[Product].[Price_in]. Visible=true
Else
[Product].[Price_in]. Visible=false
End
以上規則是在配置文件中的，可方便修改而不用修改程序和進行編譯，也可以緩存起來以提高性能。
規則的表現形式可以是xml，腳本，邏輯語言，圖像，如果能實現一個規則設計器可以大大方便規則的制定，降低規則學習的門檻。
因為要保證規則的全局性，那么對所有的數據查詢，修改都要經過這個規則校驗，因此數據操作需要一個集中的入口或者出口，所有對數據的操作都要有個用戶id，規則引擎根據id和規則庫來校驗操作的合法性。
因為要保證界面權限和模型權限的一致性，因此要開發一套可以根據權限來自動展現的控件庫。
引入規則引擎對開發模式影響也是很大的，由於業務規則從系統中分離出來，數據的基本操作都可以變成簡單的增刪改，有利於程序自動統一處理。開發的重點變成了開發規則執行的規則，簡單的說就是制定規則的規則。系統初始化后只有一個設計器，通過設計器建立行業模型，再通過設計器對模型進行規則限制，這些工作將轉移到實施部門進行，不需要開發部門進行干預。由於建立一套行業規則的工作量是很大的，因此可以預置幾套行業規則模板，同一套系統在不同的規則下來適應不同的行業業務。
改造后的系統最終變成 “原型系統+規則=行業軟件”，當然此想法很初步和不成熟，建立一套這樣的系統難度和初期工作量也很大，但是一旦建立起來后系統靈活性大大提高，后期隨業務變更變的容易，變更成本更低，更具市場競爭力。
朱現國 2014-04-24