什么时候不应该使用规则引擎？[关闭]

对于使用规则引擎的优势，我有相当不错的清单，以及使用它们的一些原因，我需要列出不应该使用规则引擎的原因的清单。

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

规则引擎并非真正旨在处理工作流或流程执行，也不是旨在设计规则的工作流引擎或流程管理工具。

还有其他重要原因为什么您不应该使用它们？

当我看到人们使用非常大的规则集（例如，单个规则集中成千上万个规则）时，我会感到非常紧张。当规则引擎是位于企业中心的单例以希望保持规则干燥时，通常会发生这种情况可以使许多需要它们的应用程序可以访问它们。我会无视任何人告诉我，具有这么多规则的Rete规则引擎是很好理解的。我不知道有什么工具可以检查以确保不存在冲突。

我认为将分区规则集保持较小是一个更好的选择。方面可以是在许多对象之间共享通用规则集的一种方式。

我希望尽可能使用更简单，更多数据驱动的方法。

我将从个人经验中举两个例子，其中使用规则引擎是个坏主意，也许会有所帮助：-

1. 在过去的项目中，我注意到规则文件（该项目使用Drools）包含许多Java代码，包括循环，函数等。它们本质上是伪装为规则文件的Java文件。当我向建筑师询问设计理由时，我被告知“规则绝不打算由业务用户维护”。

课程：由于某种原因，它们被称为“业务规则”，当您无法设计可由业务用户轻松维护/理解的系统时，请勿使用规则。

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

课程：在初始发行版更改期间，需求往往会发生很大变化，并且不保证使用规则。当您的业务经常变化时使用规则（不是要求）。例如：随着税法的变化和规则的使用，一个执行税费的软件每年都会更改，这是个好主意。Web应用程序的1.0版会随着用户确定新要求而经常更改，但会随着时间的推移而稳定下来。不要将规则用作代码部署的替代方法。

我是业务规则引擎的忠实拥护者，因为它可以帮助您简化程序员的生活。在从事数据仓库项目时，我的最初经历之一就是找到包含遍布整个页面的复杂CASE结构的存储过程。调试是一场噩梦，因为很难理解在如此长的CASE结构中应用的逻辑，并且很难确定代码第1页的规则和第5页的规则之间是否有重叠。代码中嵌入了300多个这样的规则。

当我们收到了一个新的开发要求时，即所谓的“ Accounting Destination”（涉及到3000多个规则），我知道有些事情必须改变。那时我一直在研究一个原型，后来成为现在的“自定义业务规则”引擎的父级，该引擎能够处理所有SQL标准运算符。最初，我们一直使用Excel作为创作工具，后来，我们创建了一个ASP.net应用程序，该应用程序允许业务用户定义自己的业务规则，而无需编写代码。现在，该系统运行良好，几乎没有错误，并且包含用于计算此“会计目的地”的7000多个规则。我认为仅通过硬编码就不可能实现这种情况。

但是，这种方法仍然有局限性：

• 您需要拥有对公司业务有深入了解的有能力的业务用户。
• 为了确定所有硬编码条件（要转换为要由业务规则引擎处理的规则），在搜索整个系统（在我们的情况下为数据仓库）中需要大量工作。我们还必须非常小心，以确保业务用户可以完全理解这些初始模板。
• 您需要有一个用于规则创作的应用程序，其中实现了用于检测重叠业务规则的算法。否则，您将陷入一团糟，那里没人再知道他们得到的结果了。当您在自定义业务规则引擎等通用组件中遇到错误时，很难调试并进行大量测试，以确保以前可以正常工作的东西现在也可以正常工作。

有关此主题的更多详细信息，请参见我写的帖子：http : //dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

总体而言，使用业务规则引擎的最大优势在于，它使用户可以收回对业务规则定义和创作的控制权，而无需每次需要修改某些内容时都去IT部门。它还减少了IT开发团队的工作量，IT开发团队现在可以专注于构建具有更多附加值的东西。

干杯，

尼古拉

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

将逻辑交给非技术人员

当您在非技术方面拥有一两个跨学科的天才时，我已经看到这项工作很棒，但是我也看到缺乏技术会导致膨胀，更多错误，并且通常是4倍的开发/维护成本。

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

我认为Alex Papadimoulis的文章很有见地：http : //thedailywtf.com/articles/soft_coding.aspx

它并不全面，但是他有一些优点。

关于何时不使用规则引擎...（以及何时使用规则引擎）...的精彩文章。

http://www.jessrules.com/guidelines.shtml

另一个选择是，如果您有一组线性规则，而这些规则只能以任何顺序应用一次才能获得结果，则可以创建一个时髦的界面，并让开发人员编写和部署这些新规则。这样做的好处是速度很快，因为通常您会传递休眠会话或jdbc会话以及任何参数，因此您可以高效地访问所有应用程序数据。有了事实清单，可能会有很多循环/匹配，这确实会减慢系统速度.....这是避免规则引擎并能够动态部署的另一种方法（是的，我们的常规规则部署在数据库，并且我们没有递归。。。它满足了规则，或者没有。这只是另一种选择.....哦，还有一个好处是不为新来的开发人员学习规则语法。

这确实取决于您的上下文。规则引擎占有一席之地，如果您在某个项目上有规则，而您可能想针对不需要规则引擎的非常简单的情况动态部署规则，则以上仅是另一种选择。

如果您有一个简单的规则集并可以使用一个时髦的界面，则基本上不要使用规则引擎.....就像动态可部署，加入您的团队的新开发人员可以比Drools语言更快地学习它。（但这是我的观点）

以我的经验，当满足以下条件时，规则引擎最有效：

1. 针对您的问题领域的明确定义的学说
2. 高质量（最好是自动化的）数据可帮助推动您的大部分输入
3. 与主题专家联系
4. 具有创建专家系统经验的软件开发人员

如果缺少这四个特征中的任何一个，您仍然可能会找到一个适合您的规则引擎，但是每次我尝试甚至缺少一个特征时，都会遇到麻烦。

那当然是一个好的开始。规则引擎的另一件事是，有些事情是容易理解的，确定性的，直截了当的。工资预扣是（或过去）那样。您可以将其表示为可由规则引擎解析的规则，但是可以将其表达为与相当简单的值表相同的规则。

因此，当您要表达具有持久性数据的长期流程时，工作流引擎会很好。规则引擎可以做类似的事情，但是您必须增加很多复杂性。

当您具有复杂的知识库并且需要搜索时，规则引擎将非常有用。规则引擎可以解决复杂的问题，并且可以快速适应不断变化的情况，但是在基础实现上带来了很多复杂性。

许多决策算法非常简单，足以表达为简单的表驱动程序，而没有真正的规则引擎所暗示的复杂性。

我强烈推荐像Drools这样的业务规则引擎作为开源，或者像LiveRules这样的商业规则引擎。

• 当您有许多本质上易变的业务策略时，很难维护核心技术代码的那部分。
• 规则引擎为框架提供了极大的灵活性，并且易于更改和部署。
• 规则引擎并不是在所有地方都可以使用，但是当您有很多策略需要定期更改时，就需要使用规则引擎。

我不太了解以下几点：
a）商界人士需要非常了解业务，或者
b）对商人的分歧不需要知道规则。

对我来说，作为一个刚刚接触BRE的人，BRE的好处就是让系统适应业务变化，因此它专注于适应变化。
是否由于以下原因而在时间x处设置的规则与时间y处设置的规则不同是否重要：
a）商界人士不了解业务，或者；
b）商界人士不了解规则？