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

Question

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

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

  

规则引擎并非真正用于处理工作流程或流程   执行也不是工作流引擎或流程管理工具   旨在制定规则。

你不应该使用它们的任何其他重要原因？

Answer 1

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

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

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

1. 另一个案例;该项目使用了规则，因为需求定义/理解不当并经常更改。开发团队的解决方案是广泛使用规则以避免频繁的代码部署。

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

Answer 2

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

我认为分区规则设置为保持较小是更好的选择。方面可以是在许多对象之间共享公共规则集的方法。

我更倾向于使用更简单，更加数据驱动的方法。

Answer 3

我是Business Rules Engines的忠实粉丝，因为它可以帮助您作为程序员让您的生活更轻松。我在处理数据仓库项目时遇到的第一个经验之一就是找到包含复杂CASE结构的存储过程，这些结构遍及整个页面。这是调试的噩梦，因为很难理解在这种长CASE结构中应用的逻辑，并确定代码的第1页和第5页的另一条规则之间是否存在重叠。总的来说，我们有代码中嵌入了300多条此类规则。

当我们收到一个新的开发要求时，对于一个名为Accounting Destination的东西，涉及处理超过3000条规则，我知道必须改变一些东西。那时候我一直在研究一个原型，后来成为现在是自定义业务规则引擎的父级，能够处理所有SQL标准运算符。最初我们一直使用Excel作为创作工具，稍后我们创建了一个ASP.net应用程序，它允许业务用户定义自己的业务规则，而无需编写代码。现在系统工作正常，错误很少，并且包含超过7000条规则来计算此会计目的地。我不认为这种情况只能通过硬编码实现。用户非常高兴他们可以定义自己的规则而不会成为他们的瓶颈。

但是，这种方法还是有限的：

• 您需要拥有对公司业务有深刻理解的有能力的业务用户。
• 搜索整个系统的工作量很大（in 我们的案例是一个数据仓库），以确定所有硬编码 有意义的条件转化为要处理的规则 业务规则引擎。我们也必须好好照顾这些 业务用户可以完全理解的初始模板。
• 您需要有一个用于规则创作的应用程序，其中 实现了用于检测重叠业务规则的算法。否则你最终会陷入一团糟，没有人能理解他们得到的结果。 如果您在通用组件（如自定义业务规则引擎）中存在错误，则可能非常难以进行调试并涉及大量测试，以确保之前可用的工作现在也能正常工作。

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

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

干杯，

尼古拉

Answer 4

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

  

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

我看到这项工作很棒，当你在非技术方面有一两个多学科天才，但我也看到缺乏技术导致膨胀，更多的错误，一般4倍的开发/维护成本。

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

Answer 5

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

这并不全面，但他有一些好处。

Answer 6

关于何时不使用规则引擎的伟大文章...（以及何时使用规则）....

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

另一个选择是，如果你有一套线性的规则，只能以任何顺序应用一次以获得结果，就是创建一个groovy接口并让开发人员编写和部署这些新规则。它的优点是速度快，因为通常你会通过hibernate会话或jdbc会话以及任何参数，这样你就可以以有效的方式访问所有的应用数据。使用事实列表，可能会有很多循环/匹配真的会降低系统速度.....这是避免规则引擎并能够动态部署的另一种方法（是的，我们的groovy规则部署在一个数据库，我们没有递归......它要么符合规则，要么没有。）这只是另一种选择.....哦，另外一个好处是没有为传入的开发人员学习规则语法。他们必须学习一些groovy，但这非常接近java，因此学习曲线要​​好得多。

这实际上取决于你的背景。规则引擎有它们的位置，如果你有一个项目规则，你可能想要为非常简化的情况（不需要规则引擎）动态部署，上面只是另一种选择。

基本上不要使用规则引擎，如果你有一个简单的规则集，而且可以有一个groovy接口......就像动态可部署一样，加入你团队的新开发人员可以比drools语言更快地学习它。（但那是我的意见）

Answer 7

根据我的经验，当以下情况属实时，规则引擎效果最佳：

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

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

Answer 8

这肯定是一个好的开始。规则引擎的另一个原因是有些事情是很容易理解的，确定性的和直截了当的。工资单扣缴是（或曾经是）这样的。您可以将其表达为可由规则引擎解析的规则，但您可以表达与相当简单的值表相同的规则。

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

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

许多决策算法很简单，表达为一个简单的表驱动程序，没有真正的规则引擎隐含的复杂性。

Answer 9

我强烈推荐像Drools as open source或Commercial Rules Engine等业务规则引擎，例如LiveRules。

• 如果您有许多易失性的业务策略，则很难维护核心技术代码的这一部分。
• 规则引擎为框架提供了极大的灵活性，并且易于更改和部署。
• 规则引擎不能在任何地方使用，但是当你有很多政策要求定期进行变更时，需要使用规则引擎。

Answer 10

我真的不明白一些观点，例如：
a）商业人士需要很好地了解业务，或者; b）对商业人士的分歧不需要了解规则。

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

Answer 11

我不久前在博客上写过。

你可以在这里查看 - ＆gt; http://www.codetoglory.com/?p=21

当你拥有像保险，交易和外汇领域一样不断变化的动态规则时，你应该真的使用它。

希望我的博客文章可以为您提供一些很好的概述。