java - 为什么我们不能用 Java 文件而不是 .drl 文件来编写业务规则？

Question

我刚刚了解了业务规则、.drl 文件、规则引擎和 Drools。在探索过程中，我意识到所有这些条件和事实检查也可以在 Java 程序中完成，那么为什么我们需要编写 .drl 文件和单独有一个规则引擎。

我在 Internet 上找到的示例没有区分为什么我们应该为特定的业务逻辑编写 .drl 文件而不是将逻辑放在 Java 类中。
使用示例进行解释会很有帮助。

Answer 1

使用规则引擎的常见优点包括:

• 声明式业务规则:使用业务分析师(而不是开发人员)可以用来定义业务规则的 DSL 允许采用类似于“让您的开发人员进行编码，而您的业务分析师管理业务规则”的方法。
• 外部化规则:这可能(取决于所选的规则引擎)允许您更改这些规则，而无需重建和重新部署整个应用程序。
• 非功能性:专用规则引擎可能比隐藏在代码中的一系列 if/then/else 子句表现更好(例如，通过并发执行)，同样，专用规则引擎可以提供更好的诊断和规则决策的可见性而不是自己动手解决。当然，这些不一定是正确的，但是可以说，如果您自己的解决方案在这方面要匹配或超过使用良好的规则引擎，那么需要进行一些重要的开发才能做到这一点。<

(还有其他的，但为了这个答案的目的，我认为以上就足够了)。

当然，这些优势或多或少取决于每个案例的具体情况。因此，例如，如果提议的业务规则非常简单、数量很少、不太可能更改，并且如果对其执行时间的期望较低，则上述许多优势都不适用。

然而，许多实现都是从小而简单开始的，并且期望 future 几乎没有变化，但所有这些期望都会受到现实的挑战:)

在某种程度上，您可以使用 Drools 并通过使用 Drool 的 Java 方言“将...逻辑放入 Java 类”也是毫无意义的。

如果您被鼓励违背自己的意愿使用 Drools，那么折衷的解决方案可能是围绕您的规则实现包装一个接口(interface)，并从该接口(interface)的简单实现开始，允许以后基于 Drools 的实现的可能性，如果/当可以提出令人信服的理由时。