在解決方案中實現業務規則引擎的方法或模式？

Question

我在一家年輕的銀行公司工作。我們的解決方案（.NET）有一個重要的技術債務，所以我們按照DDD原則重構它。我們計劃使用（a）業務規則引擎。業務規則涉及會計目的，營銷目的，風險目的，法律事務......我們正在計劃將BRE由業務贊助。

我在尋找一些成功採用BRE或BREs組合的人的反饋？

• 是否有管理BR存儲庫的工具？
• 是否有任何可能有助於分離流程和BR的模式？
• 您是否知道一些撰寫有關將解決方案遷移到 BRE的作者？
• 您是否認爲採用獨特的BRE可滿足所有領域的需求， 還是爲每個域定製解決方案的原型更好？
• 什麼是常見的陷阱？

感謝，

Answer 1

所以，這是一個有點誇大其詞，但我還沒有看到一個業務規則引擎很好地工作在生產環境中。唯一一次我看到它們工作正常的時候，他們被視爲完全像他們正在替換的代碼庫。

他們需要遵循一個SDLC，通過需求收集，開發（與工程師），質量保證，並最終推廣到生產。

規則引擎通常作爲繞過開發，測試和源代碼管理成本的方式出售給商業人士。這些系統通常很快就會崩潰。規則是編程邏輯，它們從某個數據庫加載而不是從文件系統加載的事實不會改變任何內容。作爲編程邏輯，最適合開發他們的人是......程序員。

當商務人士嘗試寫這些東西時，他們傾向於在系統不能阻止流程陷入邏輯漏洞時相當快地感到沮喪。程序員習慣於思考的東西。

這確實只是一個保真問題。您正在交易高保真編程語言（java，c，python），以實現低保真語言。你不是神奇地使決策點的數量變小。你只是用一種必然更加約束的語言來表達它們。當你用低保真語言來表達你的更復雜的問題時，你最終會創造一個怪物。數百或數千條規則串聯在一起。只有一兩個人能夠理解它，它很快就會成爲組織的巨大責任。

也許你的公司是不同的，但我已經看到這種情況發生了幾次，通常唯一的出路就是報廢和重建。我見過業務工作流引擎工作得很好。以相當高級的方式協調低層邏輯塊的事情。但是將所有真正的決策留給較低級別​​的機器。這些也是，需要保持在他們的位置，並有可行的推廣，卡瓦爾等。