【发布时间】：2010-10-20 23:36:15
【问题描述】：
我有一个相当不错的使用规则引擎的优点列表，以及使用它们的一些原因，我需要的是你不应该使用规则引擎的原因列表
到目前为止，我最好的是：
规则引擎并非真正用于处理工作流或流程 执行也不是工作流引擎或流程管理工具 旨在做规则。
您不应该使用它们的任何其他重要原因？
【问题讨论】：
标签： rule-engine
【发布时间】：2010-10-20 23:36:15
【问题描述】：
我将根据个人经验举两个例子，说明使用规则引擎是个坏主意，也许这会有所帮助：-
- 在过去的一个项目中，我注意到规则文件（该项目使用 Drools）包含很多 java 代码，包括循环、函数等。它们本质上是伪装成规则文件的 java 文件。当我向架构师询问他设计的理由时，我被告知“这些规则从未打算由业务用户维护”。
教训：它们被称为“业务规则”是有原因的，当您无法设计出一个业务用户可以轻松维护/理解的系统时，不要使用规则。
- 另一个案例；该项目使用规则是因为需求定义/理解不充分并且经常更改。开发团队的解决方案是广泛使用规则来避免频繁的代码部署。
教训：在初始版本更改期间，需求往往会发生很大变化，并且不保证使用规则。当您的业务经常变化时使用规则（不是要求）。例如：-随着税法的变化和规则的使用，每年都会改变税收的软件是一个好主意。 Web 应用程序的 1.0 版本会随着用户识别新需求而经常更改，但会随着时间的推移而稳定下来。不要使用规则来替代代码部署。
【讨论】：
-
我认为重新表述你的第 2 课的一个好方法是“当你知道 DSL 包含的抽象可能会改变时，不要实现 DSL。”设计和实施 DSL 是一个需要大量资源的过程，您的目标是在未来获得奖励。如果您必须在每个周期重新创建 DSL，那么规则引擎将不适合，直到某些稳定发生。
-
DSL 可能会占用大量资源，因为解释性编程语言很繁重，但它们也可以像其他编译语言一样是静态类型并在更改时编译。
当我看到人们使用非常大的规则集（例如，在一个规则集中有数千条规则）时，我会感到非常紧张。当规则引擎是位于企业中心的单例时，通常会发生这种情况，希望保留规则DRY 将使许多需要它们的应用程序可以访问它们。我会拒绝任何人告诉我具有这么多规则的 Rete 规则引擎是很好理解的。我不知道有任何工具可以检查以确保不存在冲突。
我认为划分规则集以保持较小是更好的选择。方面可以是在许多对象之间共享通用规则集的一种方式。
我更喜欢尽可能简单、更多以数据为驱动的方法。
【讨论】：
-
不会确定是否有任何冲突是停机问题的变体吗？
-
不知道您是否会这样称呼它。使用该名称会发生什么变化？我什么都看不到...
-
@duffymo 有什么“更多数据驱动方法”的例子吗？
-
当然：将您的资料放在一个决策表中并进行查询以获得您想要的答案。无需 Rete 规则引擎。
我注意到“双刃剑”的一点是：
将逻辑交到非技术人员手中
当您在非技术方面拥有一两个跨学科天才时，我看到这项工作非常出色，但我也看到缺乏技术导致臃肿、更多错误，以及通常 4 倍的开发/维护成本。
因此，您需要认真考虑您的用户群。
【讨论】：
-
如果（她）不能使用你的系统，或者如果他（她）不断地用它实现不可预知的结果，那是你作为程序员的错，而不是用户的错，无论它是否是 BRE .我想说，责怪用户无法使用你的代码是项目可能拥有的绝对糟糕的编程类型。
-
虽然这是一篇很老的帖子，但我不能同意更多。我认为如果可能的话，技术人员（或供应商）在实施/入职过程中为客户进行配置，然后根据服务请求进行任何重大更改。
-
也许有人会发现阅读 Martin Fowler 写的一篇关于 DSL-s 的好文章会有所帮助：“DSL 是否允许业务人员在不涉及程序员的情况下编写软件规则？” martinfowler.com/bliki/BusinessReadableDSL.html
我是业务规则引擎的忠实粉丝，因为它可以帮助您让程序员的生活变得更轻松。在从事数据仓库项目时，我的第一个经验是找到包含跨越整个页面的复杂 CASE 结构的存储过程。调试是一场噩梦，因为很难理解在如此长的 CASE 结构中应用的逻辑，也很难确定代码第 1 页的规则与第 5 页的规则是否重叠。总的来说，我们有代码中嵌入了 300 多个这样的规则。
当我们收到一个新的开发要求时，称为会计目标，它涉及处理超过 3000 条规则，我知道有些事情必须改变。那时我一直在研究一个原型，该原型后来成为现在是自定义业务规则引擎的父级，能够处理所有 SQL 标准运算符。最初我们一直使用 Excel 作为创作工具，后来，我们创建了一个 ASP.net 应用程序，它允许业务用户定义他们自己的业务规则，而无需编写代码。现在系统运行良好，几乎没有错误，并且包含超过 7000 条用于计算此计费目标的规则。我认为仅通过硬编码是不可能出现这种情况的。用户很高兴他们可以定义自己的规则，而 IT 不会成为他们的瓶颈。
不过，这种方法还是有局限性的：
- 您需要有能力的业务用户，对公司业务有很好的了解。
- 搜索整个系统（在 我们的案例是一个数据仓库），以确定所有硬编码的 有意义的条件转化为要处理的规则 业务规则引擎。我们还必须注意这些 商业用户完全理解的初始模板。
- 您需要有一个用于规则创作的应用程序，其中 实现了用于检测重叠业务规则的算法。否则你最终会陷入一团糟，没有人知道他们得到的结果。 当您在自定义业务规则引擎等通用组件中出现错误时，可能会非常难以调试，并且需要进行大量测试以确保以前可以正常工作的东西现在也可以正常工作。
可以在我写的帖子中找到有关此主题的更多详细信息：http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx
总体而言，使用业务规则引擎的最大优势在于它允许用户收回对业务规则定义和创作的控制权，而无需在每次需要修改某些内容时都去 IT 部门。它还减少了 IT 开发团队的工作量，现在可以专注于构建具有更多附加值的东西。
干杯，
尼古拉
【讨论】：
关于何时不使用规则引擎的精彩文章......（以及何时使用）......
http://www.jessrules.com/guidelines.shtml
另一个选择是，如果您有一组仅以任何顺序应用一次以获得结果的线性规则，则可以创建一个 groovy 界面并让开发人员编写和部署这些新规则。优点是速度非常快，因为通常您会传递休眠会话或 jdbc 会话以及任何参数，因此您可以访问所有应用程序数据，但以一种有效的方式。使用事实列表，可能会有很多循环/匹配，这确实会减慢系统速度.....这是避免规则引擎并能够动态部署的另一种方法（是的，我们的 groovy 规则部署在数据库，我们没有递归......它要么符合规则，要么没有）。这只是另一种选择.....哦，还有一个好处是不需要为新来的开发人员学习规则语法。他们必须学习一些 groovy，但这与 java 非常接近，因此学习曲线要好得多。
这真的取决于你的上下文。规则引擎占有一席之地，如果您的项目有规则，您可能希望为不需要规则引擎的非常简化的情况动态部署规则，那么上述只是另一种选择。
如果你有一个简单的规则集并且可以有一个 groovy 界面，则基本上不要使用规则引擎......就像动态部署和加入你的团队的新开发人员可以比 drools 语言更快地学习它一样。（但那是我的意见）
【讨论】：
-
不幸的是，该链接不再有效。我刚收到 404。
根据我的经验，当满足以下条件时，规则引擎最有效：
- 为您的问题领域定义明确的原则
- 高质量（最好是自动化）数据有助于推动您的大部分输入
- 访问主题专家
- 具有创建专家系统经验的软件开发人员
如果缺少这四个特征中的任何一个，您仍然可能会发现一个规则引擎适合您，但每次我尝试它时即使缺少 1 个，我都会遇到麻烦。
【讨论】：
-
this>_具有创建专家系统经验的软件开发人员_
这当然是一个好的开始。规则引擎的另一件事是，有些事情是容易理解的、确定性的和直截了当的。工资预扣是（或曾经是）这样的。您可以将其表示为可由规则引擎解析的规则，但您也可以将相同的规则表示为一个相当简单的值表。
因此，当您要表达具有持久性数据的长期流程时，工作流引擎是很好的选择。规则引擎可以做类似的事情，但你必须做很多额外的复杂性。
当您拥有复杂的知识库并需要搜索时，规则引擎非常有用。规则引擎可以解决复杂的问题，并且可以快速适应不断变化的情况，但会给基础实现带来很多复杂性。
许多决策算法足够简单，可以表达为简单的表驱动程序，而没有真正规则引擎所暗示的复杂性。
【讨论】：
我强烈推荐像 Drools as open source 或 Commercial Rules Engine 这样的业务规则引擎，比如 LiveRules。
- 当您拥有大量易变的业务策略时，很难维护这部分核心技术代码。
- 规则引擎为框架提供了极大的灵活性，并且易于更改和部署。
- 规则引擎并非在任何地方都可以使用，但需要在您有大量策略且不可避免地需要定期更改时使用。
【讨论】：
我不太明白一些点，例如：
a) 业务人员需要非常了解业务，或者；
b) 商界人士的意见分歧不需要知道规则。
对我来说，作为一个刚接触BRE的人，BRE的好处就是所谓的让系统适应业务变化，所以重点是适应变化。
在时间 x 设置的规则是否与在时间 y 设置的规则不同是否重要，因为：
a) 业务人员不懂业务，或者；
b) 商务人士不懂规则？
【讨论】：