111

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

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

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

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

4

9 回答 9

157

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

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

教训：它们被称为“业务规则”是有原因的，当您无法设计一个业务用户可以轻松维护/理解的系统时，不要使用规则。

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

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

于 2009-12-30T22:52:12.553 回答
37

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

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

我更喜欢尽可能简单、更多数据驱动的方法。

于 2009-04-22T00:15:42.283 回答
20

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

将逻辑交给非技术人员

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

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

于 2009-04-22T00:00:46.783 回答
19

我是业务规则引擎的忠实拥护者，因为它可以帮助您让程序员的生活更轻松。在处理数据仓库项目时，我的第一个经验是找到包含跨越整个页面的复杂 CASE 结构的存储过程。调试是一场噩梦，因为很难理解在如此长的 CASE 结构中应用的逻辑，也很难确定代码第 1 页的规则与第 5 页的规则是否重叠。总的来说，我们有代码中嵌入了 300 多个这样的规则。

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

尽管如此，这种方法还是有局限性的：

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

关于这个主题的更多细节可以在我写的一篇文章中找到：http: //dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

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

干杯，

尼古拉

于 2012-01-22T08:58:33.690 回答
11

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

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

另一种选择是，如果您有一组仅按任何顺序应用一次以获得结果的线性规则，则创建一个 groovy 界面并让开发人员编写和部署这些新规则。优点是速度非常快，因为通常您会传递休眠会话或 jdbc 会话以及任何参数，因此您可以访问所有应用程序数据，但以一种有效的方式。使用事实列表，可能会有很多循环/匹配确实会减慢系统速度.....这是避免规则引擎并能够动态部署的另一种方法（是的，我们的 groovy 规则部署在数据库，我们没有递归......它要么符合规则，要么没有）。这只是另一种选择.....哦，还有一个好处是不需要为新来的开发人员学习规则语法。

这真的取决于你的上下文。规则引擎有它们的位置，如果您在项目中有规则，您可能希望为不需要规则引擎的非常简化的情况动态部署规则引擎，那么上述只是另一种选择。

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

于 2011-11-04T17:50:55.147 回答
8

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

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

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

于 2009-09-30T15:37:56.803 回答
1

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

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

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

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

于 2009-04-21T23:57:01.893 回答
0

我不太了解某些要点，例如：
a）业务人员需要非常了解业务，或者；
b) 业务上的分歧不需要知道规则。

对我来说，作为一个刚接触BRE的人，BRE的好处就是所谓的让系统适应业务变化，所以它的重点是适应变化。
在时间 x 建立的规则是否与在时间 y 建立的规则不同是否重要，因为：
a) 业务人员不了解业务，或；
b) 商务人士不懂规则？

于 2013-05-21T14:04:23.753 回答
0

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

  • 当您有许多本质上易变的业务策略时，很难维护这部分核心技术代码。
  • 规则引擎为框架提供了极大的灵活性，并且易于更改和部署。
  • 规则引擎不是在任何地方都可以使用，而是在您有很多策略不可避免地定期更改时需要使用。
于 2013-04-30T13:43:54.553 回答