java - 为什么使用规则引擎而不是易于理解的一行属性？

Question

我是规则引擎的新手，所以如果这个问题非常基本，请耐心等待。规则引擎的所有教程都在说，您可以将业务逻辑移出代码并由 BA/最终用户更新，而不是将其放在 Java 代码中。

我有以下问题

1. 但是为什么我们不能编写代码来从属性文件中读取值并做同样的事情呢？

2. 此外，与 .properties 文件相比，规则文件的语法似乎不仅仅是单行的。

3. 将这些规则放入规则引擎是否可以使代码/应用程序工作而无需重新启动应用程序服务器？

   3a。如果没有，那么我们如何实现它？

Answer 1

最近几天一直在做一些阅读，我认为（恕我直言），允许使用简单的电子表格更新业务规则的能力，使规则引擎比属性文件更具优势。我可以使用多个属性和将规则修改为每个属性下的注释的说明，使属性文件尽可能高度可配置。

但在业务用户能够直接配置应用程序以根据电子表格中的“决策表”应用值的情况下，该解决方案将更可取。

如果任何其他（初出茅庐的）开发人员正在寻找规则引擎需要的理由，对此答案深信不疑，请竖起大拇指！

Answer 2

1. 如果逻辑发生变化，您将更改属性文件并再次部署整个项目。然而，如果您使用 BRMS 维护它，您可以仅在 BRMS 上单独更改和测试，而无需再次部署整个项目。一旦测试完成并且您最终想要部署新规则，那么也无需在生产中部署整个项目。如果您使用 KIE 服务器将规则公开为 API，则只需重新部署 KIE 服务器即可。
2. 可以以这样一种方式编写决策表，即所有逻辑都包含在最上面的行中。然后开发人员可以锁定和隐藏那些顶行，然后将其提供给 BA。现在 BA 看不到任何逻辑，但知道如何维护文件。此外，并非所有逻辑都应该写成决策表。
3. 正如我上面提到的，可以将每条规则部署为单独的休息 API，因此可以独立于其他规则进行部署。

最后，我想说我们使用 Redhat BRMS 的主要原因是，正如他们在文档中提到的那样：

1. 敏捷性：无需让开发人员参与更改请求。BA的自己可以改变逻辑。
2. 可见性：所见即所得（在 excel 中）。
3. 一致性：每次都以相同的方式评估规则。

Answer 3

规则引擎只是组织许多规则的算法。请参阅Rete 算法。

基本上，这一切都归结为复杂性。如果您有一些简单的规则，当然可以使用 .properties 文件。但是想象一下，如果你的一些规则是“链式的”——一个规则会影响其他一些属性，这会触发一些其他规则，从而改变另一个属性……你必须扫描每一个规则，每一个变化。对于成千上万的规则，这将需要永远。因此是“规则引擎”。

关于为什么应该或不应该使用规则引擎的文章有很多。这是一个很好的例子。 https://martinfowler.com/bliki/RulesEngine.html

Answer 4

规则引擎并不总是答案。但是，它们在理论上提供了引擎可以对简单的规则表达式执行复杂处理并返回结果的优势。其他优点是对规则的可见性和更少的代码。

回答您的问题。

1. 你可以。在简单的情况下，使用属性文件是有意义的。

2. 规则需要足够复杂以涵盖他们验证的业务问题。一个好的规则引擎使用可读的语法，即使它很复杂。

3. 理论上，规则服务器可以独立于应用服务器运行。在大公司，这很正常。规则服务器可以在不重新启动的情况下允许更新，或者可以在不影响应用服务器的情况下重新启动（波纹，如果有多个实例）。

Answer 5

1. 当公司的业务用户想要设置某些规则并根据规则集的执行结果/结果决策来驱动应用程序时，规则引擎就会出现。此类公司的示例之一可能是律师事务所或保险公司，其中律师制定规则来推动保险的报价计算，并且规则会随着时间的推移而发生变化。属性文件是业务用户可能不擅长进行更改的开发人员区域。拥有单独的规则引擎可以跟踪规则并使业务用户和开发人员一起工作，从而无缝地自动化业务，这对于属性文件来说可能很困难。
2. 规则文件语法是将业务规则（口头）转换为可执行的编码指令的方法。这就是语法出现的地方。这样，规则引擎为业务实体及其关系提供数据抽象。
3. 与规则引擎的集成可以通过某些代理或 Web 服务或任何其他方式完成，基于此，服务器应用程序需要规则客户端 jar 来进行调用。因此，如果规则客户端 jar 更新，它的部署问题以及服务器如何获取更改/热部署。