我是规则引擎的新手，如果这个问题很基本，请耐心回答。所有针对规则引擎的教程都说，您可以将业务逻辑转移到代码之外，并由BA/最终用户进行更新，而不是将其放在Java代码中。
我有以下问题
-
但是为什么我们不能编写代码来读取属性文件中的值并做同样的事情呢？
-
此外，与.properties文件相比，规则文件的语法似乎不仅仅是一行代码。
-
将这些规则放入规则引擎是否可以使代码/应用程序在不需要重新启动应用程序服务器的情况下工作？
3a。如果没有，那么我们该如何实现呢？
过去几天一直在阅读，我认为(这是IMHO)允许使用简单的电子表格更新业务规则的能力使规则引擎比属性文件更具优势。我可以使用多个属性使属性文件尽可能高度可配置，并在每个属性下使用修改规则的说明作为注释。
但是，在业务用户能够直接配置应用程序以基于电子表格中的"决策表"应用值的情况下，该解决方案将更可取。
如果任何其他(萌芽中的)开发人员正在为规则引擎的需求寻找理由，并确信这个答案，请留下大拇指！
- 如果逻辑发生变化，您将更改属性文件并重新部署整个项目。然而，如果您使用BRMS来维护它，则可以更改&只在BRMS上单独测试，而无需再次部署整个项目。一旦测试完成，并且您最终希望将新规则部署到位，那么也不需要在生产中部署整个项目。如果您已经使用KIE服务器将您的规则公开为API，则只重新部署KIE服务器即可
- 可以这样写决策表，即所有逻辑都包含在最上面的行中。然后开发者可以锁定&隐藏那些最上面的行，然后把它交给BA。现在BA看不到任何逻辑，但知道如何维护文件。此外，并不是所有的逻辑都应该写成决策表
- 如上所述，可以将每个规则部署为单独的rest API，因此可以独立于其余规则进行部署
最后，我想说我们使用Redhat BRMS的主要原因是，正如他们在文档中提到的那样：
- 敏捷性：无需让开发人员参与变更请求。BA本身可以改变逻辑
- 可见性：你在excel中看到的就是你得到的
- 一致性：每次都以相同的方式评估规则
规则引擎只是组织许多规则的算法。请参阅Rete算法。
基本上，这一切都归结为复杂性。如果您有一些简单的规则，当然可以使用.properties文件。但想象一下，如果你的一些规则是"连锁的"——一个规则影响了另一个属性，这会触发另一个规则，从而改变另一个特性。。。你必须仔细检查每一条规则，每一个变化。对于成千上万的规则来说，这将需要很长时间。因此产生了一个"规则引擎"。
关于为什么应该或不应该使用规则引擎，有很多文章。这里有一个很好的例子。https://martinfowler.com/bliki/RulesEngine.html
规则引擎并不总是答案。然而，从理论上讲，它们提供了一个优势，即引擎可以对简单的规则表达式执行复杂的处理并返回结果。其他优点是规则的可见性和更少的代码。
回答您的问题。
-
你可以。在简单的情况下，使用属性文件是有意义的。
-
规则需要足够复杂，以涵盖它们验证的业务问题。一个好的规则引擎使用可读的语法，即使它很复杂。
-
理论上，规则服务器可以独立于应用程序服务器运行。在大公司，这是正常的。规则服务器可以在不重新启动的情况下允许更新，也可以在不影响应用程序服务器的情况下重新启动(如果有多个实例，则会产生涟漪)。
- 当公司的业务用户想要设置某些规则并根据规则集的执行结果/结果决策来驱动应用程序时，规则引擎就会出现。这样的公司的例子之一可以是律师事务所或保险公司，其中律师制定规则来驱动保险公司的报价计算；规则会随着时间的推移而变化。属性文件是开发人员的领域，业务用户可能不擅长进行更改。单独的规则引擎可以跟踪规则，并使业务用户和开发人员协同工作，无缝地自动化业务，这在使用属性文件时可能很困难
- 规则文件语法是将业务规则(口头)转换为可执行的编码指令的方法。这就是语法的用武之地。通过这种方式，规则引擎为业务实体及其关系提供了数据抽象
- 与规则引擎的集成可以通过一些代理或web服务或其他什么来完成，在此基础上，服务器应用程序需要规则客户端jar来进行调用。所以，它的问题是部署，以及如果更新了规则客户端jar，服务器如何进行更改/热部署