在我們的項目中，我們必須實現關於將某些對象映射到某些操作的業務邏輯。在某個動作最終得到解決之前，我們將針對特定類型的對象進行一系列的驗證。換句話說，對於7種類型的對象，我們可以有一系列的動作（從近45個動作中）。Drools是映射業務規則/邏輯的最有效方法嗎？
我們正在考慮使用Drools寫下上述規則。就其效率而言，有沒有人對使用Drools有一些正面/負面的經驗？還有可以使用的jBPM框架（如果我沒有錯誤地使用Drools） - 任何人都熟悉該框架？也許你還有其他一些關於如何解決問題的想法？
關於效率，你應該沒有任何問題與Drools。對我來說，這聽起來像是一小撮事實和規則。它所基於的Rete引擎在做出決策時幾乎肯定比任何你自己編寫的if-then-else語句更快。我注意到一個特別的好處是響應時間是非常可預測的。
顯然，所有的事實模型和規則都有所不同，但作爲一個例子，我目前構建的應用程序在任何時候都有數百個工作記憶中的事實，並且有超過1000條規則。它能夠在大約20毫秒內做出關於傳入請求的決定。
完整的jBPM框架對於您所描述的內容來說不是必需的。不過，它擅長它。例如，如果您想要設計工作流程，就有一個流程建模GUI，如果技術團隊在編寫DSL和構建決策表時做了一些前期工作，Guvnor可以用於非技術規則的作者。
爲了保持完整性，主要競爭對手可能是FICO Blaze Adviser或IBM ILog JRules。一般來說，當涉及到基準測試時，它們往往略高於Drools，但價格昂貴。無可否認，如果您決定爲JBoss/RedHat服務合同付費，那麼它就沒有多大區別，但如果您很樂意在Drools上獲得社區支持，那麼它是免費的！
我唯一關心的是Drools沒有像非IT業務人員可以真正使用的體面GUI。許多產品聲稱他們確實提供這樣的用戶界面，但事實證明它並不是真的。所以，您必須接受這樣一個事實，即您的開發團隊最終將根據決策表或其他格式創建和測試所有這些規則。
除此之外，Drools是政府，銀行和大公司使用的一個很棒的BRE。
100％爲真。但是，根據他給出的解釋，也許決策表可能是一個很好的候選人。如果是這樣的話，規則可以由沒有IT人員的少量痛苦來管理。 –
@EstebanAliverti理論上你絕對正確。決策表的整個前提是將IT從業務中抽象出來。但事實上，這從來不起作用。我一直在處理15年的BRE，經歷了所有的大事件。我從來沒有見過一個項目，商業人士不需要IT部門的幫助就可以創建/編輯表格。格式/動作/條件一直在變，新的商務人士進來等等。 – Kizz
謝謝您的迴應！我們決定在我們的項目中使用Drools，我們對此非常滿意。當然，GUI有一個問題，但您可以使用電子表格中的決策表來覆蓋它。我在我的博客上有一篇文章[鏈接]（http://toomuchcoding.blogspot.com/2013/02/drools-decision-tables-with-camel-and.html） –
Drools是非常有效和快速。但是與任何技術框架一樣，它需要投資才能整合到您的項目中，這不是一個神奇的子彈。你需要考慮：
jBPM不是規則引擎，它是一個工作流引擎。 Drools是一個規則引擎。所以Drools就是你要找的東西。
Drools和jBPM是配套項目：如果您需要帶規則的工作流程，它們集成得非常好。
Drools良好JBPM與其他BPMN引擎相比有點複雜。我建議去Activiti，因爲它比較容易，並且集成了Spring，LDAP等任何東西。 Activiti更容易。你也可以將Drools和Activiti整合在一起..所以去Activiti作爲一個工作流引擎和Drools作爲規則引擎。
感謝您的回覆！我們決定在我們的項目中使用Drools，我們對此非常滿意。一件非常好的事情是我們將規則保留在DRL文件中，並且我們不必每次都重新部署應用程序。 –