包含规则引擎的系统是不是曾经真正成功过？ [关闭]

Posted 2023-05-08

【中文标题】包含规则引擎的系统是不是曾经真正成功过？ [关闭]

【英文标题】：Has a system that incorporated a rule engine ever been TRULY successful? [closed]包含规则引擎的系统是否曾经真正成功过？ [关闭]

【发布时间】：2010-09-17 09:52:55

【问题描述】：

我们的系统（外来商品衍生品交易捕获和风险管理）即将重新开发。我听到的一个建议是，将合并一个规则引擎，以使最终用户（商品交易商，相当老练）更容易对业务逻辑进行某些更改。

我对规则引擎有点怀疑。我的敏捷者想知道它们是否只是流程问题的技术解决方案……即。我们的开发人员需要很长时间才能响应业务的变化需求。该问题的解决方案应该是更协作的开发方法、更好的测试覆盖率、更敏捷的实践。

了解规则引擎真正带来好处的情况（尤其是在交易环境中）肯定会有所帮助。

【问题讨论】：

我投票决定将此问题作为离题结束，因为它是对故事的请求，而不是编程问题。

【参考方案1】：

我见过两个使用 Fair Issac 的 Blaze Rete 引擎的应用程序。

一个应用程序将数千条规则撞到一个知识库中，出现了严重的内存问题，已成为一个很少人理解的黑匣子。我不会称之为成功，但它正在生产中运行。

另一个应用程序使用决策树来表示医疗表格上数百个问题，以处置客户。它做得非常优雅，业务人员可以根据需要更新规则，而无需开发人员参与。 （不过，仍然必须部署一个。）我认为这是一个巨大的成功。

因此，这取决于问题的重点程度、规则集的大小以及开发人员的知识。我的偏见是，简单地让规则引擎成为单点故障并将规则转储到其中可能不是一个好方法。我会从数据驱动或表驱动的方法开始，然后不断发展，直到需要规则引擎。我还努力将规则引擎封装为对象行为的一部分。我会向用户隐藏规则引擎，并尝试将规则空间划分到域模型中。

【参考方案2】：

我不知道我是否会说它们是真正的福音，但我认为它们肯定是有价值的。我在保险行业的一个系统上工作了几年，该系统非常成功地使用了一个规则引擎，允许业务用户创建规则来确定哪些政策是合法的，具体取决于州。

例如，如果您在某些州必须有共付额，或者出于产品考虑，或者因为州法律纯粹是非法的，而某些自付额和共付额的组合是不允许的。

公司运营所在的州的数量，以及规则的不断变化（每季度）将使这成为令人眼花缭乱的编码实践。更重要的是，这不是程序员的专业知识。它增加了额外的毫无意义的沟通，最终用户向不是保险行业专家的程序员描述要生效的规则。

如果设计得当，规则引擎仍然可以启用允许进行良好测试的工作流系统。在这种情况下，规则存储在数据库中，并且有 QA 和 PROD 数据库。所以 BA 可以在 QA 中测试他们的规则，然后将它们提升为 PROD。

与任何事情一样，它通常与实现有关，而不是实际技术。

【参考方案3】：

是的，Microsoft 在 BizTalk 中有一个已成功使用多年的业务规则引擎 (BRE)。我听说他们有客户为 BRE 购买 BizTalk（非常昂贵）。

根据我的经验，让业务用户更新规则的实用性微乎其微。业务规则编辑器通常需要技术人员。

【参考方案4】：

规则引擎只不过是执行声明性语句的东西。它们有两个主要优点（我看到）：

您的业务逻辑是从一个地方维护的，而不是分散在整个应用程序代码中。从技术上讲，无论是否存在规则引擎，一个设计良好的应用程序都应该在架构上做到这一点。 您需要[更少]担心声明性语句之间的依赖关系。规则引擎应该足够聪明，可以根据依赖关系决定运行规则的顺序。您可能会发现某些规则引擎支持在规则集中按顺序排列规则或以特定顺序调用规则集（规则组），但这并不真正符合声明式编程的精神。许多规则引擎使用 Rete（一种算法）来决定何时安排声明性语句的执行。

我怀疑大多数（如果不是全部）规则引擎会比您编写不使用规则引擎的最佳程序增加更多开销。这类似于在汇编中编写代码通常比编译器更快（但您通常不编写汇编，因为使用更高级别的抽象更方便和高效）。

如果您要到此为止，那么您可能会使用程序员来维护规则并使用规则引擎作为在应用程序中构建业务逻辑层的便捷方式。一些规则引擎提供称为模板的东西，让您可以为规则定义模板。这里的好处是非技术用户应该能够编写自己的规则并修改现有规则。

规则引擎是您工具箱中的另一种工具，如果使用得当，它会很有价值。

【参考方案5】：

其中许多规则引擎的问题在于速度不够快，而且替换或扩充规则可能会以微妙的方式破坏现有的工作规则。因此，您仍然需要在每次规则更改后彻底重新测试系统。因此，您基本上只是将一种计算机语言换成另一种计算机语言——一种用户群少得多的计算机语言。正如另一位发帖人所提到的，我还没有看到业务分析师成功使用规则引擎。反正你需要一个程序员。

【参考方案6】：

我当然有，但不能公开谈论他们，但今年你可能已经和他们互动过好几次了；）

我在两个阵营中看到它：逻辑程序员和业务用户。不同的工具针对不同的集合，有些两者兼而有之。业务用户的成功案例仅在它是逻辑的子集时才有效，并且他们也有办法定义测试用例并自己运行它们（并且他们准备进行逻辑思考）。 逻辑程序员很少见，但通常可以从非命令式编程背景中找到（他们也是那种认为函数式编程直观的人）。

在一天结束时请记住，即使使用可视化工具，如果您要告诉计算机做某事，它仍在编程。

【参考方案7】：

我与该领域的许多供应商合作，其中一件很棒的事情是我可以与他们的许多客户交谈。所以，是的，数百家公司完全获得了他们所承诺的好处 - 提高敏捷性、更好的业务/IT 协作、更容易遵守法规、更好的决策一致性、更低的维护成本、更快的上市时间等等。

在所有主要供应商和开源参与者中，我一次又一次地看到，这种做法被正确地使用了——通过许多规则、变化很大的规则、以复杂方式交互的规则来自动化和改进大量运营决策或具有高业务领域内容的规则 - 业务规则管理系统工作。

真的。

【参考方案8】：

我的经验仅限于（i）不多和（ii）序言；但我可以肯定地说，规则引擎可以帮助您表达比程序代码更简洁的命题概念。

【参考方案9】：

规则引擎通常用于保险业务。我曾在具有数百（600 条）规则的系统上工作，这些规则在规则引擎中实现。效果很好。

【参考方案10】：

您有信用等级吗？ FICO 分数，也许？这就是 Fair Isaac COrporation，Blaze 规则引擎的开发者。

【参考方案11】：

我曾在 PEATE 分布式计算项目工作过一段时间，该项目正在开发一个用于计算大规模、大量大气数据的系统。该系统由三个部分组成：数据管理器、调度器和算法执行组件。可以有任意数量的这些组件，全部通过 Web 服务完成，但它允许不同的研究人员针对任意数据执行任意作业，并且还允许随着需求的变化插入不同的调度机制。

我在项目离地太远之前就离开了，但这似乎可能适合该场景，并作为某种规则引擎的另一个示例。然而，话虽如此，如果原始开发人员仍然要让算法运行，我看不出拥有规则引擎有太多好处，除非它处理每个规则或算法会产生的大量开销它是自己的。

这听起来比简单的规则引擎要复杂一些，但这样的架构也可以应用于规则引擎。