目錄
何時使用規則引擎
規則引擎是一個非常強大的組件。在我們定義規則邏輯的時候，它爲我們提供了大量的變化。它允許我們可以在非常短的時間內完成對我們系統複雜度、性能和穩定性的處理。
這些改進對一些系統是很有用的，業務規則可以在你發現的一些類型的系統裏進行實現和添加。儘管如此，我們還是想備註下在技術棧中引入業務規則會帶來更多好處的系統。這些項目具有以下一個或幾個特徵：
- 它們定義了非常複雜的場景，甚至連業務專家都無法滿足
- 沒有開源的或容易編寫的算法解決
- 需求容易變且經常更新
- 基於一定量的數據進行快速決策
複雜的場景、簡單的規則
隨着我們不斷的研究，每隔一段時間，我們就發現系統或者系統的一部分組件之間的小關係就開始越重要。起初，它們看起來大概是個無害的組建，它們基於兩三個數據源之間的小關係來做一些小決策。未來隨着我們開始對它深入研究，這些關係越來越重要。最終，我們可能發現這些關係之間會產生更多集體性行爲，甚至連業務專家都沒注意到這種行爲會發生的，但是這種行爲又是有意義的。這種系統我們稱之爲複雜系統，業務規則可以給這種系統提供更多的幫助。
複雜場景往往都是由小陳述定義的。從全局來看，涉及到每個完成定義場景所需要的組合、聚合和數據的抽象，通常都在我們最初掌握的東西之外。因此，這些系統是通過部分解釋開始定義的。系統中每個小關係都被定義爲不同的需求。當我們分析這些需求的時候，將其分解爲最基本的節點，我們就會發現我們自己需要定義的規則。
每個業務規則都可以幫助定義複雜場景中的每個小組件。隨着越來越多的規則添加到系統中，它們之間越來越多的關係可以使用簡單遺易讀的方式處理。當執行復雜場景的時候，每個規則會成爲系統做的每個小決策的自解釋手冊。複雜應用的例子有很多，正如下面所述：
- 欺詐檢測系統：通常它們會從中央服務器中拿到每個完成訂單的交易，並深入調查它們之間的相關行，以確定訂單來自非誠實合法使用系統的情況。比如說異常的信號卡操作、穩定的賬戶中存在大量的活動、交易中存在非法的參數等通常都是這類系統要尋找的。
- 自定義回頭客零售優惠券：在各種商業活動中，客戶的忠誠度是非常重要的。常用的策略是基於客戶的購物習慣對指定的優惠券設置最大數量。爲了可以發正確的券，一個複雜的系統需要評估客戶的購買記錄，將用戶框在指定的統計組裏，併爲組選擇最好的選擇。這些所有的事情需要基於他們的購買記錄和購買趨勢的複雜關係來完成。
- 信用評分系統：信用評分是基於的個人信用文件的級別去表示用戶信用價值的數學表達式。每個債務、信貸、購買或者關係都可以成爲有效的數據來源，都決定着個人的信用。這個場景的複雜度來源於，必須基於所有的數據來源的相關性來關聯、衡量和返回出指定的分數
不斷變化的場景
當我們不需要處理複雜的場景，我們只是想通過業務規則來更好的處理程序的邏輯。如果在做一部分決策的時候所涉及的元素變化趨於頻繁，業務規則可以成爲一個良好的管理易變的系統行爲的解決方法。
業務規則在規則引擎中表現爲一個數據樹。與修改列表中元素的方式相同，我們可以從規則引擎中添加和移除規則。它可以在無需重啓應用和重新安裝任何組件的完成。Drools6框架提供了通過外部資源自動更新規則定義的內部方式。Drools6框架也準備提供對用戶好友的編輯工具進行更新規則的方式。Drools6的api完整框架是基於讓其儘可能的自適應。
如果你發現一個系統的需求變化非常頻繁，甚至每天或每小時都在發生變化。由於規則引擎的更新能力，業務規則非常適合這種需求的系統，而不管系統的複雜度如何。
示例-eShop系統
這本書的其他部分，我們會致力於基於相同領域的規則組成的決策服務的集合：eShop應用。實踐是學習新框架的關鍵部分，爲了更簡單，也爲了儘可能快的瞭解規則引擎的詳情，我們將會定義可以在大多數例子中共享的模型。
開始之前，我們將會定義eShop系統的模型。這些模型將會包括我們應用制定決策時相關的不同的事情。下面表示的就是這些模型：
- 產品：我們的系統將會賣不同種類的商品。每種商品都將會以產品對象存在，而且包含指定商品的詳情。
- 庫存：每種產品存儲的數量。
- 供應商：每中產品都來自不同的供應商。他們每個人通過不同的交貨方式爲eShop提供特定類型的商品。
- 供應商請求：當產品過少或超賣時，我們將會向供應商創建供應商請求以充實庫存。
- 客戶：eShop中對特定商品有特殊偏好的人，正在或已完成訂單，特定的人物統計信息（標籤）、支付偏好（支付首選項）和其他可以從eShop中獲得的偏好的數據。
- 訂單：當一個客戶喜歡eShop中的一個或者多個產品時，他們會商品進行下單交付。依賴於用戶是否已經成功收到商品，訂單有不同的狀態。訂單中還有訂單中商品的數量信息。
- 優惠：eShop提供了不同類型的優惠，具體取決於購買類型。
- 售賣渠道：eShop會與多個網站合作，它們每個作爲不同的售賣渠道。每個售賣渠道都有其特定的目標受衆，這是由使用它的用戶決定的。
因爲我們需要更多類型的對象去定義eShop中的現實實體，我們會定義更多的類來擴展對我們世界的瞭解。一旦我們將所有領域數據關聯在一起，我們將能檢測所有類型的情況，並且可以做出最有利於eShop和客戶的行爲。如下所示，這些是我們將可以做的事情：
- 通過將產品和售賣渠道關聯然後對比其他渠道，給特定種類的商品定義最好的售賣渠道。基於這些信息，我們可以爲產品在這些渠道創建自定義優惠。
- 爲特定的產品定義客戶偏好，基於這些信息，我們可以針對不同的口味爲它們提供優惠券。
- 確定指定產品的平均消耗，然後跟其庫存進行對比。如果可能，我們可以自動觸發供應商請求。
- 基於我們爲供應商提供的訂單數量，我們可以要求優惠價格。
- 我們可以分析客戶在我們系統不同的購買記錄。如果在某些時候，購買記錄超過我們認爲的正常範圍，我們可以做一些行動，從簡單的警告到爲特定的購買記錄提供人員支持（客服人員介入）。
這些只是我們通過這些領域的業務規則做的事情。當我們發現有很多情況來滿足特定的需求時，我們將會學習到更多關於編寫規則和配置運行時環境的技術。爲了充分利用Drools6框架，每個新的必需技術都會指導我們定義新的組件。
何時不使用規則引擎
每個工程都會或多或少的從使用業務規則中受益。它是高效率、容易改變和自解釋性的軟件組件。但是，一個工程大概有一個條件分組，這會讓業務規則太具備殺傷力。從業務規則獲取收益更少的工程有如下所示的特徵：
工程中涉及很少的規則：如果在需求收集中確定的業務規則非常簡單，最多隻會跨越一兩個對象，那我們就沒必要使用規則引擎。一個好的經驗法則是如果我們寫的規則代碼需要至少一頁的僞代碼至少有兩個嵌套的if-then，在這種情況下，我們大概是不需要規則引擎的。
- 業務規則不經常變化：如果不需要在運行期修改規則但是邏輯複雜，這時候使用規則引擎應該是一個好主意。但是，如果規則背後的複雜性沒那麼高，而且我們假設它會保持很久這種狀態，我們大概不需要使用規則引擎。
- 對於應用程序來說，非常嚴格控制的執行流程至關重要：正如我們之前描述的，當執行我們的業務規則時，無法控制程序流。如果規則背後的業務邏輯依賴非常嚴格的按順序執行的步驟集，業務規則大概不適合這種。但是如果它變化的非常頻繁，大概值得考慮下業務流。
是否適合使用業務規則，一直是工程團隊需要決定的責任，即使所有的條件都滿足。畢竟，我們的經驗可以讓我們思考，將來規則的數量有大量的增長或者可能出現規則最終需要頻繁的改變的場景。每個工程都有不同的特徵，如果沒有這些特徵，將來無法考量一些現在不需要業務規則的工程。
總結
當傳統的開發者首次遇到處理業務規則時，業務規則是一個很奇怪的概念，我們第一章的目的是介紹如何在日常應用開發中適應它們以及爲什麼它們可以幫助我們去定義更好的系統。
我們看到了業務規則是什麼，定義了規則的結構，並介紹了它的部分使用。我們也介紹了一些適用業務規則的示例工程，還有一些沒有必要使用規則的示例。我們也介紹了eShop工程，它會通過下一章指導我們，以便確定Drools6框架提供的從業務規則編寫到規則引擎配置的所有的好處。
在下一章，我們將開始編寫第一個業務規則，並邁出第一步去定義基於業務規則的項目。