基於規則系統組織商務規則

同步自：http://www.blogjava.net/AndersLin/archive/2006/06/30/55926.html

2007.12.20更新部分內容        
分析階段的Use Case（User Story）除了Business Flow描述外，另一個重要的部分就是商務規則。組織和實現這些商務規則有不同的手段（將帶來不同效益）。除傳統的開發人員的代碼實現外，越來越多系統開始使用規則系統來組織。 

對於應用規則引擎網路上著名的有兩篇文章：《Java規則引擎與其API應用詳解》和《企業平台中的商務規則引擎》
此外，JBoss也基於Drools推出了JBPM。Oracle也推出了自己的規則產品。 
  
不過在應用規則引擎前，需要瞭解四個問題： 
第一個問題是：什麼算是商務規則？
我以為《Business Rules Applied》一書對Business Rule的分類比較合理： 
 

Constraint	A constraint can be a mandatory restriction or suggested restriction on the behavior of the business event. A mandatory constraint is a complete statement that expresses an unconditional circumstance that must be true or not true for the business event to complete with integrity. Examples of mandatory constraints are: A customer must not have more than 10 open orders at one time. The total dollar amount of a customer order must not be greater than the customer’s single order credit limit amount.
Guideline	A guideline is a complete statement that expresses a warning about a circumstance that should be true or not true. A guideline does not force the circumstance to be true or not true, but merely warns about it, allowing the human to make the decision. Because a guideline only warns and does not reject, it provides a freedom of choice. An example of a guideline is: A customer should not have more than 10 open orders at one time.
Action enabler	A complete statement that tests conditions and upon finding them true, initiates another business event, message, or other activity. That is, an action enabler initiates a new action external to the scope of the system or increment under study. Examples of action enablers are: If a customer order is valid, then initiate the Place Order process. If a customer is high risk, then notify the customer services manager. Action-enabler rules can be used in some commercial rules products to create an event-oriented sequence of workflow steps. It may be helpful to think of mandatory constraints and action enablers as opposites. Mandatory constraints stop an event from completing. Action enablers start an event.
Computation	A complete statement that provides an algorithm for arriving at the value of a term where such algorithms may include sum, difference, product, quotient, count, maximum, minimum, average. An example of a computation rule is:     The total-amount-due for an order is computed as the sum of the lineitem amount(s) for the order plus tax.
Inference	A complete statement that tests conditions and upon finding them true, establishes the truth of a new fact. Examples of inferences are: If a customer has no outstanding invoices, then the customer is of preferred status.     If a customer is of preferred status, then the customer’s order qualifies for a 20 percent discount.

 
需要強調一下的是（以下想法十分的不成熟）：
規則中不應該處理商務程序（任何具有實際意義的業務操作），只有規則本身。包括：
A. 不在規則中更新Domain Object的屬性；
B. 不訪問Dao對象的建立，更新和刪除的持久化工作；
C. 不訪問Domain Service中任何涉及Domain Object更新、網路訪問、檔案操作和郵件操作等方法；
D. 只產生提供控制資訊或者狀態資訊等runtime資料，由商務程序來完成A，B和C限制的行為。
 
第二個問題是：要確定的是否所有的控制邏輯都要用可定製的商務規則來解決？
答案很明顯，並非所有的地方都需要。
很多控制邏輯細節都可以採用參數化配置來完成，採用參數配置對於提高效能也有好處。當然參數化配置意味著，對應的控制邏輯的業務邊界是確定的。一旦面對高度客戶化的商務邏輯，就需要採用規則系統了。
 
第三個問題是：如果要，那麼我們需要一個什麼類型的規則系統？
規則系統的分類（以下是我的分類）：
根據功能，規則系統可以分兩類：Formula系統和正統的rule系統。我把Formula系統看作是一個弱化的rule系統，只做公式計算，Excel用的最多的功能也是這個。
根據語言，規則系統可以分兩類：程式設計語言規則系統和類DSL規則系統。類DSL更接近自然語言，更接近問題描述語言。
根據引擎，又可以分為指令碼系統和推理系統。如JRule就同時支援兩種技術：checklist和forward chain，當用checklist時就是一個指令碼系統。BTW：Ajoo同學的JASKELL是一個不錯的指令碼系統。
使用什麼的規則系統，取決於系統的需要。
更多的時候系統不需要做推理（因為設計的時候人都做了），一個指令碼系統就可以滿足需要，而一個弱化後的Formula系統更簡單實用。
 
下面是我在javaeye上開的一個和這個有關的話題：
規則系統or指令碼系統，自然語言，DSL or Java語言
 
第四個問題是：一旦確定了使用規則系統，該系統的受眾是誰，即誰使用該系統？
受眾是開發人員還是客戶將是一個問題。
如果是開發人員，所要做的工作就是把設計好的對象映射到規則系統中，不需要額外的工作。而如果是客戶，或許要多做些工作了。
問題的所在是：通常系統設計採用OO原則，而OO追求的是細粒度的設計，這點對於開發人員來說不是什麼問題。但對於客戶來說則不一樣，客戶看到的或者說說理解的物件模型（如果他能理解的話）是一個粗粒度的概念。於是我們不得不額外做些工作——封裝不同對象（關聯的）到一個對象中。
 
一旦使用了類DSL的規則系統，我們關心的就不是程式，而是一個問題描述。雖然類DSL規則系統最終將產生程式碼（利用代碼產生技術），但是很明顯，我們所關心的更接近於Use Case（User Story）。無論是開發人員還是客戶都將更容易理解系統的行為。
 
同樣，因為採用的是代碼生產技術——產生式編程（又拔了一個高度，hoho），綜合效益顯然（這個……廣告語）。更多請參考《產生式編程》一書