最近，我正在閱讀關於JBOSS Drools手冊中的規則引擎[ref - 2.2.5。強而鬆的耦合]。下面是它的摘錄'如果你的規則都是強烈耦合的，那麼規則可能會有未來的不靈活性，更重要的是，規則引擎可能是過度殺傷性的（因爲邏輯是一個明確的規則鏈，並且可以被硬編碼[決策樹可能是有序的]）。這並不是說強或弱的耦合本質上是不好的，但是在考慮規則引擎時以及如何捕獲規則時要記住這一點。 「鬆散」耦合的規則應該會導致一個系統，允許更改，刪除和添加規則，而不需要更改不相關的其他規則。正在使用規則引擎來實現規則鏈[複雜的業務邏輯]矯枉過正？
這是否意味着，規則引擎不適合執行復雜業務邏輯[緊密耦合的規則或規則鏈]的選項。
在我目前的項目中，我們有規則鏈，即1規則的結果決定另一個規則的結果等等。該應用程序有許多內部變量來鏈接規則。我認爲規則引擎可以幫助處理具有聲明性規則和動態業務邏輯的額外優勢的複雜性。
討論在這方面會有所幫助......
我覺得這一切都取決於用戶界面上，而不是規則（一個或多個）包含實際的邏輯（一個或多個）。請記住，今天的大多數引擎都是基於決策表的心態。而所有這些「強大而鬆散的耦合」只不過是用來作爲糟糕用戶界面或缺乏用戶藉口的熱門詞彙。正常引擎可以處理任何複雜規則的執行。請注意，這是我個人的觀點，很多人會完全不同意。所以，請不要急於降級我的答案，我只是想幫助:)
典型的概念是，具有複雜邏輯的規則看起來真的「搞砸了」，甚至不可能在決策中實現表。通常情況下，人們試圖通過將複雜的規則分成更小的簡單規則並根據執行優先級將它們堆疊到規則集中來解決這個問題。
有些新的引擎通過實現括號而不是優先級來決定無表的UI。括號也有助於複雜性。
「避免強耦合」與「避免複雜性」無關。
文件提倡的是，你不應該從另一個規則中調用一個規則，相反，每個規則應該產生一個結果，而結果本身應該引發鏈中的下一個規則。這種規則不關心接下來發生的事情，而是處理事實（aha！）。如果不是爲事實編寫規則，而是專注於編寫普通的過程邏輯流程，那麼您並不需要增加規則引擎的複雜性。
這種差異很微妙，但並不比「不把業務邏輯放在視圖中」或「不要將數據庫訪問代碼放入業務邏輯」等規則更微妙。
即使您完全瞭解您需要執行的測試的順序和性質，以及應該產生的操作，某些邏輯也並非易事。例如公司審計，對援助計劃的測試，保險法規等。
今天的大多數規則引擎開始包含一個決策表特徵，它在所有現實中都引入了一些「有限強耦合」（我不知道如果這真的是一個術語，但它是我理解ILOG，Drools等系統中的效果）。這是有益的，因爲一些測試，只是與其他測試和決策表都遠遠更好地爲構建這些測試比IF THEN ELSE結構。
Corticon（專有規則引擎）和DTRules（一個開源的規則引擎）只是折騰了整個鬆耦合規則的做法，只是建立決策表。這個想法是讓你決定建設（數額爲決策樹一切下方）一個很好的結構是許多應用程序更加容易。
在IBM ILOG JRules的方法有很多，你可以代表你的規則。
因此，您可以決定在哪種方式下，您可以使用上述三種方式來適合將複雜規則分解爲更簡單的形式。
您可以使用規則流編排與條件流，以解決「1條規則的結果將是另一個規則的輸入」
我同意。就像谷歌阻止互聯網發展一樣，決策表減緩了規則引擎的發展 – 2011-07-01 22:30:19