这更像是一般性问题。但我试图理解使用工具的概念以及为什么需要这个工具。我一直在四处走动。
q）为什么我们需要规则引擎？
我一直在阅读Drools和ILOG规则引擎，我仍然不清楚组织使用这些工具可以获得什么好处的概念。
q）是否只是为业务用户提供了一种向数据库（存储库）发出查询（被称为规则）的方法？
与获得的收益相比，这个额外的s / w是否只会花费更多的资金用于许可和支持？
我们总是让所有的应用程序做同样的事情。
实施例： 如果销售＆lt; $ 5000000然后订单发货=否
以上是业务逻辑的示例。这很容易在程序中实现。那么通过规则引擎获得的好处是什么？
任何输入都会很棒！ 谢谢。
答案 0 :(得分：2)
您是否看过这个文档：Why should I use a rule engine ?
很明显何时使用而不使用规则引擎。
仔细看看这2个paragrpahs：
1.2.5。强而松散的耦合
毫无疑问，您已经听过“紧耦合”和“松散”之类的术语 耦合“在系统设计中。通常人们断言”松散“或 由于添加，“弱”耦合在设计方面是优选的 它提供的灵活性。同样，你可以“强烈耦合”和 “弱耦合”规则。在这个意义上强烈耦合意味着一个 规则“解雇”显然会导致另一条规则被解雇，依此类推; 换句话说，有一个明确的（可能是显而易见的）逻辑链。如果 你的规则都是强烈耦合的，很可能是意志 结果是不灵活，更重要的是，这是一个规则引擎 太过分了。清晰的链可以硬编码，或使用实现 决策树。这并不是说强耦合本质上就是这样 不好，但在考虑规则引擎时要记住这一点 以及捕获规则的方式。 “松散”耦合的规则应该 导致系统允许更改，删除和添加规则 无需更改其他不相关的规则。
和
在我看来，在使用规则引擎的兴奋中， 人们忘记了规则引擎只是复杂的一部分 应用或解决方案。规则引擎并非真正意图 处理工作流程或流程执行，也不是工作流引擎或 旨在制定规则的流程管理工具。使用正确的工具 工作。当然，一把钳子可以用作锤子工具 捏，但这不是它的设计目的。 --Dave Hamu
希望有所帮助
答案 1 :(得分：1)
使用业务规则引擎或业务规则管理套件有很多优点。当您开始使用声明性方法将业务逻辑与应用程序分离时，您最终会在这些规则中表达您的业务知识。对于能够在集中式存储库中拥有所有知识并且所有应用程序都可以重复使用的公司而言，这一事实非常有价值。
在我看来，声明能力也是一个关键概念。让引擎选择特定情况所需的规则的想法很棒。规则引擎针对此目的进行了优化，并且当您有大量必须评估的规则时，它们会非常出色。
希望有所帮助：）