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

我有一个相当不错的使用规则引擎的优势列表，以及一些使用它们的理由，我需要的是一个为什么你不应该使用规则引擎的理由列表

到目前为止，我能想到的最好的是:

规则引擎实际上并不打算处理工作流或流程 也不是工作流引擎或过程管理工具 是为了遵守规则而设计的。

还有其他不应该使用它们的重要原因吗？

125007 次浏览
小开

That's certainly a good start. The other thing with rules engines is that some things are well-understood, deterministic, and straight-forward. Payroll withholding is (or use to be) like that. You 可以 express it as rules that would be resolved by a rules engine, but you could express the same rules as a fairly simple table of values.

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

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

许多决策算法非常简单，可以表示为一个简单的表驱动程序，而不需要真正的规则引擎所暗示的复杂性。

小开

The one poit I've noticed to be "the double edged sword" is:

把逻辑交给非技术人员

I've seen this work great, when you have one or two multidisciplinary geniuses on the non technical side, but I've also seen the lack of technicity leading to bloat, more bugs, and in general 4x the development/maintenance cost.

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

小开
最佳答案

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

我认为分区规则集保持它们很小是一个更好的选择。方面可以是在许多对象之间共享公共规则集的一种方法。

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

小开

根据我的经验，规则引擎在以下情况下工作得最好:

  1. 为您的问题领域定义良好的原则
  2. 高质量(最好是自动化的)数据有助于驱动大部分输入
  3. 接触专题专家
  4. 有创建专家系统经验的软件开发人员

如果这四个特性中的任何一个缺失了，您仍然可能会发现一个规则引擎可以为您工作，但是每次我尝试它时，哪怕只缺少1个，我都会遇到麻烦。

小开

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

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

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

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

经验 : 在初始版本更改期间，需求往往会发生很大的变化，并且不需要使用规则。当您的业务经常更改时使用规则(而不是需求)。随着税法的改变和规则的使用，一个为你报税的软件每年都会改变，这是一个非常好的主意。Web 应用程序的发布1.0会随着用户识别新需求而经常发生变化，但随着时间的推移会趋于稳定。不要使用规则作为代码部署的替代方法。

小开

关于何时不使用规则引擎... (以及何时使用规则引擎) ... 的文章很棒。

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

另一种选择是，如果您有一组线性规则，这些规则在任何顺序下只应用一次，那么创建一个 groovy 接口，并让开发人员编写和部署这些新规则。它的优点是速度非常快，因为通常您会传递休眠会话或 jdbc 会话以及任何参数，这样您就可以访问所有的应用程序数据，但是要以一种高效的方式。有了事实列表，可以有很多循环/匹配，真的可以减慢系统的速度... ... 这是另一种避免规则引擎和能够动态部署的方法(是的，我们的 groovy 规则部署在数据库中，我们没有递归... ... 它要么符合规则，要么不符合)。这只是另一种选择... ... 哦，还有一个好处是不需要为即将到来的开发人员学习规则语法。他们必须学习一些常规语言，但是这与 Java 非常接近，所以学习曲线要好得多。

这完全取决于你所处的环境。规则引擎有自己的位置，如果您有一个项目上的规则，您可能希望动态部署这些规则，以满足不需要规则引擎的非常简单的情况，那么上述规则引擎只是另一种选择。

BASICALLY do NOT use a rules engine if you have a simple ruleset and can have a groovy interface instead.....just as dynamically deployable and new developers joining your team can learn it faster than the drools language.(but that's my opinion)

小开

我是业务规则引擎的忠实粉丝，因为它可以帮助您作为一个程序员的生活变得更加轻松。我在从事数据仓库项目时的第一次经历之一是发现存储过程包含复杂的 CASE 结构，这些结构延伸到整个页面。调试是一场噩梦，因为很难理解在如此长的 CASE 结构中应用的逻辑，也很难确定代码第1页的规则和第5页的规则之间是否有重叠。总的来说，我们在代码中嵌入了300多条这样的规则。

When we've received a new development requirement, for something called Accounting Destination, which was involving treating more than 3000 rules, i knew something had to change. Back then I've been working on a prototype which later on become the parent of what now is a Custom Business Rule engine, capable of handling all SQL standard operators. Initially we've been using Excel as an authoring tool and , later on, we've created an ASP.net application which will allow the Business Users to define their own business rules, without the need of writing code. Now the system works fine, with very few bugs, and contains over 7000 rules for calculating this Accounting Destination. I don't think such scenario would have been possible by just hard-coding. And the users are pretty happy that they can define their own rules without IT becoming their bottleneck.

Still, there are limits to such approach:

  • You need to have capable business users which have an excellent understanding of the company business.
  • 搜索整个系统(在 我们的情况一个数据仓库) ，以确定所有硬编码 这些条件有意义地转化为需要处理的规则 一个业务规则引擎。我们还必须注意这些 业务用户完全理解的初始模板。
  • You need to have an application used for rules authoring, in which 实现了重叠业务规则的检测算法。否则，你最终会搞得一团糟，没有人再理解他们得到的结果。 When you have a bug in a generic component like a Custom Business Rule Engine, it can be very difficult to debug and involve extensive tests to make sure that things that worked before also work now.

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

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

干杯,

尼古拉

小开

我强烈推荐业务规则引擎，如 流口水作为开源或 商业规则引擎，如 LiveRules。

  • When you have a lot of business policies which are volatile in nature, it is very hard to maintain that part of the core technology code.
  • 规则引擎为框架提供了极大的灵活性，并且易于更改和部署。
  • Rules engines are not to be used everywhere but need to used when you have lot of policies where changes are inevitable on a regular basis.
小开

我真的不明白一些观点，比如:
A)商务人士需要非常了解商务，或;
2)商业上的分歧，人们不需要知道规则。

对我来说，作为一个刚刚接触 BRE 的人，BRE 的好处被称为让系统适应业务变化，因此它的重点是适应变化。
在时间 x 建立的规则是否与在时间 y 建立的规则不同，这有关系吗，因为:
A)生意人不懂生意，或者;
B)商人不懂规矩？


提交答案