我们的系统（外来商品衍生品交易捕获和风险管理）即将重新开发。我听到的一个建议是，将合并一个规则引擎，以使最终用户（商品交易者，相当复杂）更容易对业务逻辑进行某些更改。
我对规则引擎有点怀疑。我的敏捷者想知道它们是否只是流程问题的技术解决方案……即。我们的开发人员需要很长时间才能响应业务的变化需求。该问题的解决方案应该是更协作的开发方法、更好的测试覆盖率、更敏捷的实践。
了解规则引擎真正带来好处的情况（尤其是在交易环境中）肯定会有所帮助。
Jim McSlim
问问题
3567 次
11 回答
13
我见过两个使用 Fair Issac 的 Blaze Rete 引擎的应用程序。
一个应用程序将数千条规则撞到一个知识库中，出现了可怕的记忆问题，已成为一个很少人理解的黑匣子。我不会称其为成功，但它正在生产中运行。
另一个应用程序使用决策树来表示医疗表格上数百个问题的顺序，以处置客户。它做得非常优雅，业务人员可以根据需要更新规则，而无需开发人员参与。（不过，仍然必须部署一个。）我认为这是一个巨大的成功。
因此，这取决于问题的集中程度、规则集的大小以及开发人员的知识。我的偏见是，简单地让规则引擎成为单点故障并将规则转储到其中可能不是一个好方法。我会从数据驱动或表驱动的方法开始，然后不断发展，直到需要规则引擎。我还努力将规则引擎封装为对象行为的一部分。我会向用户隐藏规则引擎，并尝试将规则空间划分为域模型。
于 2008-10-16T02:04:41.910 回答
10
我不知道我是否会说它们真的是一个福音，但我认为它们肯定是有价值的。我在保险行业的一个系统上工作了几年，该系统非常成功地使用了规则引擎，允许业务用户创建规则来确定哪些政策是合法的，具体取决于州。
例如，如果您在某些州必须有共付额，或者由于产品考虑，或者由于州法律它完全是非法的，因此不允许某些自付额和共付额的组合。
公司经营所在的州的数量，以及规则的不断变化（每季度）将使这成为一种令人眼花缭乱的编码实践。更重要的是，这不是程序员的专业知识。它增加了额外的毫无意义的沟通，最终用户正在向不是保险行业专家的程序员描述要生效的规则。
如果设计得当，规则引擎仍然可以启用允许进行良好测试的工作流系统。在这种情况下，规则存储在数据库中，并且有 QA 和 PROD 数据库。因此，BA 可以在 QA 中测试他们的规则，然后将它们提升为 PROD。
与任何事情一样，它通常与实现有关，而不是实际技术。
于 2008-10-15T21:04:08.303 回答
5
是的，Microsoft 在 BizTalk 中有一个已成功使用多年的业务规则引擎 (BRE)。我听说他们有客户为 BRE 购买 BizTalk（非常昂贵）。
以我的经验，让业务用户更新规则的实用性微乎其微。业务规则编辑器通常需要技术人员来工作。
于 2008-10-15T21:20:09.597 回答
4
规则引擎只不过是执行声明性语句的东西。它们有两个主要优点（我看到）：
- 您的业务逻辑是从一个地方维护的，而不是分散在整个应用程序代码中。从技术上讲，一个设计良好的应用程序应该已经在架构上做到了这一点，无论是否存在规则引擎。
- 您需要[更少]担心声明性语句之间的依赖关系。规则引擎应该足够聪明，可以根据依赖关系决定运行规则的顺序。您可能会发现某些规则引擎支持在规则集中按顺序排列规则或以特定顺序调用规则集（规则组），但这并不真正符合声明式编程的精神。许多规则引擎使用 Rete（一种算法）来决定何时安排声明性语句的执行。
我怀疑大多数（如果不是全部）规则引擎会比您编写不使用规则引擎的最佳程序增加更多开销。这类似于在汇编中编写代码通常比编译器更快（但您通常不编写汇编，因为使用更高级别的抽象更方便和高效）。
如果您要在这里停下来，那么您可能会使用程序员来维护规则并使用规则引擎作为在应用程序中构建业务逻辑层的便捷方式。一些规则引擎提供称为模板的东西，让您可以为规则定义模板。这里的优点是非技术用户应该能够编写自己的规则并修改现有规则。
规则引擎是您工具箱中的另一种工具，如果使用得当，它会很有价值。
于 2008-10-27T22:59:36.920 回答
3
许多这些规则引擎的问题是缺乏速度，并且替换或增加规则可能会以微妙的方式破坏现有的工作规则。因此，在每次规则更改后，您仍然需要彻底重新测试系统。因此，您基本上只是将一种计算机语言换成另一种计算机语言——一种用户群少得多的计算机语言。正如另一位发帖人所提到的，我还没有看到业务分析师成功使用规则引擎。无论如何，你需要一个程序员。
于 2008-10-15T21:33:36.903 回答
3
我当然有，但不能公开谈论它们，但今年你很可能与其中一个互动过几次；）
我在两个阵营中看到它：逻辑程序员和业务用户。不同的工具针对不同的集合，有些两者兼而有之。业务用户的成功案例仅在它是逻辑的子集时才有效，并且他们也有办法定义测试用例并自己运行它们（并且他们准备进行逻辑思考）。逻辑程序员很少见，但通常可以从非命令式编程背景中找到（他们也是那种认为函数式编程直观的人）。
在一天结束时请记住，即使使用可视化工具，如果您要告诉计算机做某事，它仍在编程。
于 2008-10-15T21:42:03.970 回答
3
我与该领域的许多供应商合作，其中一件很棒的事情是我可以与他们的很多客户交谈。所以，是的，数百家公司完全得到了他们所承诺的好处——提高敏捷性、更好的业务/IT 协作、更容易的法规遵从性、更好的决策一致性、更低的维护成本、更快的上市时间等。
一遍又一遍，在所有主要供应商和开源参与者中，我看到它使用正确 - 自动化和改进具有许多规则的大量运营决策，改变很多的规则，以复杂方式交互的规则或规则一个高业务领域内容——业务规则管理系统的工作。
真的。
于 2009-06-04T21:29:45.297 回答
2
我的经验仅限于（i）不多和（ii）序言；但我可以肯定地说，规则引擎可以帮助您表达比程序代码更清晰的命题概念。
于 2008-10-15T20:55:25.560 回答
2
规则引擎通常用于保险业务。我曾在具有数百（600 条）规则的系统上工作，这些规则在规则引擎中实现。它工作得很好。
于 2008-12-09T21:21:59.990 回答
2
你有信用等级吗？也许是FICO分数？那就是Fair I saac CO rporation ， Blaze 规则引擎的开发者。
于 2009-05-31T21:58:13.187 回答
0
有一段时间，我为 PEATE 分布式计算项目工作，该项目正在开发一个用于计算大规模、大量大气数据的系统。该系统由三个部分组成：数据管理器、调度器和算法执行组件。可以有任意数量的任何这些组件，所有这些都通过 Web 服务完成，但它允许不同的研究人员针对任意数据执行任意作业，并且还允许随着需求的变化插入不同的调度机制。
我在项目离地太远之前离开了项目，但这似乎可能适合该场景，并作为某种规则引擎的另一个示例。然而，话虽如此，如果原始开发人员仍然要让算法运行，我看不出拥有规则引擎有太多好处，除非它处理每个规则或算法会产生的大量开销它自己的。
这听起来比简单的规则引擎要复杂一些，但这样的架构也可以适用于规则引擎。
于 2008-10-15T21:19:45.653 回答