什么时候不应该使用规则引擎？

Question

我有一个相当不错的列表，列出了使用规则引擎的优点，以及使用它们的一些原因，我需要的是不应该使用规则引擎的原因的列表

到目前为止，我得到的最好的结果是：

规则引擎实际上并不是用来处理工作流或流程执行的，工作流引擎或流程管理工具也不是用来执行规则的。

你不应该使用它们的其他重要原因是什么？

Answer 1

当我看到人们使用非常大的规则集(例如，在单个规则集中有数千条规则)时，我会非常紧张。当规则引擎处于企业的中心，希望保持规则DRY能够让许多需要它们的应用程序访问它们时，经常会发生这种情况。我敢说任何人都不会告诉我，一个拥有这么多规则的Rete规则引擎是很容易理解的。我不知道有什么工具可以检查以确保冲突不存在。

我认为对规则集进行分区以使其保持较小是一个更好的选择。方面可以是在多个对象之间共享公共规则集的一种方式。

只要有可能，我更喜欢一种更简单、更数据驱动的方法。

Answer 2

我将从个人经验中举两个例子，说明使用规则引擎是一个糟糕的想法，也许这会有所帮助：

1. 在过去的一个项目中，我注意到规则文件(项目使用Drools)包含了大量的java代码，包括循环、函数等，它们本质上是伪装成规则文件的java文件。当我问架构师关于设计的理由时，我被告知“规则从来不是由业务用户维护的”。

Lesson：它们被称为“业务规则”是有原因的，当您不能设计一个易于由业务用户维护/理解的系统时，不要使用规则。

1. 是另一种情况；该项目使用规则是因为需求定义/理解得很差，而且经常更改。开发团队的解决方案是广泛使用规则，以避免频繁的代码部署。

Lesson：在初始版本更改期间，需求往往会发生很大变化，并且不保证规则的使用。当您的业务经常变化(而不是需求)时，请使用规则。随着税法的变化和规则的使用，一个做你的税务的软件每年都会改变，这是一个很好的想法。随着用户识别新的需求，web应用的1.0版本会经常发生变化，但会随着时间的推移而稳定下来。不要使用规则作为代码部署的替代方案。​

Answer 3

我注意到的一个问题是“双刃剑”：

将逻辑放在非技术人员手中

当你在非技术方面有一两个多学科的天才时，我已经看到了这种工作很好，但我也看到了缺乏技术导致臃肿，更多的bug，以及通常4倍的开发/维护成本。

因此，你需要认真考虑你的用户群。