300字范文 > 现实虚拟世界_现实世界的规则引擎

现实虚拟世界_现实世界的规则引擎

时间：2020-12-26 20:26:46

相关推荐

现实虚拟世界_现实世界的规则引擎

现实虚拟世界

对于许多开发人员而言，规则引擎是流行语或体系结构图上的黑匣子：远远地值得人们敬畏或赞赏的事物，但尚不可理解。顺便说一句，这是技术的22个陷阱之一：

在拥有一些第一手的现实世界经验之前，很难知道何时使用某种技术或如何很好地应用它。获得经验的最常见方法是在实际项目中使用未知技术。在生产环境中使用新技术获得第一手经验对于将来的工作而言是宝贵的经验，但可能会对手头的工作构成重大风险。

在本文的整个过程中，我将与规则引擎（尤其是Drools）分享我的实践经验，以支持金融服务的市场解决方案，以帮助您了解规则引擎在哪些方面有用以及如何最好地应用它们解决您面临的问题。

我为什么要在乎？

你们中的某些人已经考虑使用规则引擎，并且会寻找有关如何很好地使用它的实用建议：模式和反模式，最佳实践和漏洞。

其他人则没有考虑使用规则引擎，也不确定如何将其应用于您正在做的工作，或者没有考虑使用规则引擎并放弃了这个想法。规则引擎可以是一种强大的方法，可用于外部化业务逻辑，授权业务用户并解决复杂的问题，其中大量细粒度的业务规则和事实相互影响。

如果您曾经使用过一系列条件语句，试图评估组合，并发现自己编写了深层嵌套的逻辑来解决问题，那么这些仅仅是规则引擎可以帮助您解开纠缠的一种方式。

当以规则方式改写时，我们一些较复杂的金融服务工作开始变得显然更容易理解。将过程条件逻辑转换为Drools业务规则的每个步骤似乎一次暴露出更多的简单性和更多的功能。

最后，如果您对以上内容不满意，请考虑一下：规则引擎是一种工具，是进行软件开发的另一种方法。工具有其长处和短处，即使您没有立即使用此工具，也应了解其折衷之处，以便将来评估和交流适用性。

规则引擎入门

在我们真正讨论何时以及如何使用规则引擎之前，有必要先解释一下规则引擎是什么。

什么是规则引擎？

规则引擎的核心是执行“业务规则”的机制。业务规则是简单的面向业务的语句，它对某种类型的业务决策进行编码，通常以if / then条件格式表达。

例如，假设保险系统的业务规则可能是：

如果满足以下所有条件，则给定汽车和驾驶员：车是红色的汽车在运动课上司机是男的驾驶员年龄在16-25岁之间结果是保险费增加了20％。

这些业务规则并非新事物：它们是业务逻辑，是许多业务软件应用程序的核心。如果您是开发人员，那么您会一次又一次地看到这些规则，将其表示为需求的一部分。他们说的话是“在星期一对三件商品的订单给予20％的折扣”或“我们不为16岁的男性提供超级摩托车的保险”。

规则引擎的主要区别在于这些规则的表达方式。而不是将它们嵌入程序中，而是以业务规则形式进行编码。此格式因规则引擎而异。

规则引擎不限于执行；它们通常带有其他工具来管理规则：通用选项允许单独或成组地创建，部署，存储，版本控制和其他类似的规则管理。

规则引擎的一个例子是Drools，它最近被JBoss小组旗下。由于Drools是免费提供的，是开源的并且具有良好的社区，因此它是探索规则引擎的良好起点，并且将是本文中使用的示例。有关其他规则引擎的更多信息，请参阅其他规则引擎侧栏。

它们如何运作？

规则引擎的本质来自驱动它的算法。一些简单的“规则引擎”只是按照您指定的顺序将过程逻辑链接在一起。多数提供复杂的匹配算法，例如Rete，Treat和Leaps，以将事实与规则联系起来，确定应运行哪些规则以及以什么顺序运行。

与其他竞争对手一样，Drools也使用Rete，这是由Charles Forgy开发的匹配算法。尽管对Rete的详细处理超出了本文的范围，但简化形式是：Rete根据规则构建树，就像状态机一样。事实作为规则的参数进入顶级节点的树，如果符合条件，则沿树向下移动，直到到达叶节点：规则后果。

Rete的作者和其他人试图通过新算法来提高Rete的成功率，新算法的结果是Treat，Leaps，Rete II和Rete III，其中一些被其他规则引擎使用。

这些匹配算法比简单地按顺序运行一系列代码段更为复杂。如果要按顺序对每个事实运行每个规则，则规则引擎可能会降低您的速度；您没有使用的规则引擎方法中存在开销。另一方面，如果将规则与数据进行匹配的工作并非轻而易举，则规则引擎的复杂程度可通过诸如条件共享之类的机制很好地节省时间，其中在多个规则中共享的一个条件可以被评估一次，而不是每个规则一次。

例如，如果您正在创建一个教育计划系统，并希望创建学生的所有可能组合并为其评分，以最大程度地让学生获得所需的课程，则规则引擎可能只会减慢您创建和评分组合的速度。另一方面，如果您有一个必须重复查询相似人口统计特征的组合的保险系统，则条件共享和模式匹配可以显着降低解决方案的整体复杂性，而无需任何自定义代码即可执行此业务流程。

您如何编写规则？

这是规则引擎差异很大的领域。有些支持相对完整或摘要形式的一种或多种现有语言，而另一些提供专有语言，而另一些仍提供可视化设计系统。

一些引擎为规则的创建和管理提供了广泛的工具支持，包括规则开发环境，而其他引擎则利用了与现有工具（从IDE到文本编辑器和电子表格）的集成。

从2.5版开始，Drools在基于XML的规则文件或与Spring或JSE 5.0批注连接的Java POJO规则以及定制开发的领域特定语言中，支持Java，Python和Groovy中的编码规则。

即将发布的Drools 3.0具有自己的规则语言，不需要XML包装器。由于新用户更容易理解这种语言，因此我将使用此语法。

在Drools 3.0 DRL中指定的上述汽车保险规则：

package com.insurance.auto

import com.insurance.auto.Driver

import com.insurance.auto.Car

import com.insurance.auto.Policy

import com.insurance.auto.Style

import com.insurance.auto.Color

import com.insurance.auto.Percentage;

rule "High Risk"

when

Driver( male=true, age >= 16, age <= 25 )

Car ( style == Style.SPORT, color==Color.RED )

$p: Policy ()

then

$p.increasePremium( new Percentage( 20 ) );

Drools在Drools 2.5中仅拥有非常有限的工具，但是Drools 3.0具有Eclipse插件，该插件支持规则的创建和调试，包括特定于域的语言扩展和自动完成。这可能是增加对Drools用户的工具支持的开始。

它们有什么用？

规则引擎各不相同；每个引擎都有其特定的优势，并且使用规则引擎所带来的收益在引擎之间并不总是相同的。但是，有一些适用于大多数规则引擎的一般素质。

首先，规则引擎是解决问题的另一种方法-不一定更好或更糟，只是有所不同。从根本上说，通用编程语言和规则引擎都可以用来解决类似的问题，尽管使用规则引擎可以更轻松地解决某些问题，而使用通用编程语言可以更轻松地解决一些问题。

规则引擎提供匹配的算法，可以确定需要运行哪些规则以及以什么顺序运行，同时仍允许规则编写者在必要时使用过滤器，工作流或冲突解决方案对这些因素施加某种控制。它们允许事实随着规则的更改而重新考虑事实，从而允许一个规则的结果影响事实基础，从而在必要时运行或取消其他规则。

即使事实和规则本身很简单，这些特质也会产生微妙的相互作用，甚至可以产生有力的结果。通常，这些特性比通用编程语言更有价值。

最后，正如我们在导言中讨论的那样，有些人希望规则引擎填充特定的模式：外部化业务逻辑，支持快速变更或赋予业务用户权力。这些方法将在下面更详细地讨论。

他们不擅长什么？

尽管只要您努力尝试，规则引擎几乎可以应用于任何问题，但它们只是工具箱中的另一个工具。它们不会替代约束编程和求解器，人工智能，工作流引擎，决策表或通用编程语言；他们只是用另一种工具补充了这套工具。

示例：汽车保险报价

尽管规则引擎的应用与规则引擎本身一样多种多样，但是记住一个特定的示例通常很有用。想象一下准备汽车保险报价的系统。它将需要一系列屏幕来收集有关客户，他或她的驾驶记录，当前的保险，汽车以及有关他或她希望收到的报价的信息。此后，系统将准备一份保险报价并将其显示给用户，然后或者在以后某个日期寻求接受。

该系统的大部分相对来说都适合使用通用编程语言进行开发，但是从客户的信息中准备报价的过程很复杂，并且要处理大量不断变化的数据，不断变化的业务规则，不断变化的法规，并且麻烦重重。进行正常的开发过程。在许多方面，这是规则引擎可以发挥作用的一种环境，您可以选择将报价准备过程委派给规则引擎。

使用规则引擎进行架构设计

规则引擎与新系统或现有系统的体系结构集成的确切方式会因特定规则引擎的具体情况而异。

服务器和嵌入式

一些规则引擎需要或需要自己的服务器，并且可以远程调用；这些非常适合已经利用分布式计算的环境，例如企业javabeans，corba和面向服务的体系结构。其他的则完全嵌入，可以直接与您的域对象一起使用，也可以直接对其进行修改。当规则与周围软件之间没有信任障碍时，最好采用此方法，否则可能需要反腐败层。

规则执行

对于尚未使用分布式计算的应用程序，嵌入式规则引擎通常具有更高的性能。面向服务器的规则引擎可以在面向服务的环境中很好地工作，并在规则引擎本身内提供可伸缩性。

规则引擎是一种选择和编排业务规则的通用方法，它不可能像完全定制的解决方案一样快，但是结构良好的规则解决方案对于整个应用程序而言不会造成重大的性能损失。

规则解决方案的性能可能落在规则本身的结构和代码上，而不是激发它们的引擎，但是特定的规则引擎在性能方面将有自己的最佳实践。在规则引擎解释输入和调度规则时，重复运行整个模式匹配算法并不罕见，因此，使这些依赖关系尽可能地稀疏是很重要的。例如，在Drools中，条件可能会在早期调度过程中重复运行，因此一个或多个特别是在计算上昂贵且经常访问的条件可能会对整体性能产生重大影响。除非您熟悉在特定规则引擎中开发规则解决方案，否则在开发过程中值得关注性能。

管理规则

规则本身可以在中央存储库中进行管理，并可以通过唯一标识符进行引用，也可以直接从文件系统或数据库中的数据存储中加载。从文件系统中加载规则可以轻松地将规则作为源代码控制系统中整个代码库的一部分进行管理，并且无需大量工具集即可对规则进行更改。另一方面，规则管理存储库以及规则创建，管理和部署工具可提高非开发人员参与规则创建的便利性，而无需了解源代码控制系统和构建脚本或在本地管理文件的版本。

Drools是嵌入式的，直接与您的域对象一起使用。可以通过多种方式加载规则，但是文件系统方法是最常见的。当前，它不提供开箱即用的解决方案来从数据库或具有管理工具的中央存储库中进行加载。

示例架构

设计一个规则引擎解决方案以创建汽车保险报价可能最终看起来像这样：

通过将报价规则保留在Web应用程序存档之外，可以在与使用服务器的应用程序不同的生命周期中进行部署和重新部署。在保持规则轻巧和实现不可知的前提下，它们所需的任何信息都将传递给它们，而不是在规则内直接检索。

通常通过选择要运行的一组“规则”来调用规则，然后在规则引擎中声明一系列事实。这些事实是规则参数可以绑定到的对象以及条件和后果可以执行的对象。一旦做出一个或多个声明，就可以调用规则引擎。尽管已选择规则的“集合”，规则引擎仍将选择要针对哪些规则运行哪些对象，并以什么顺序运行。规则可以修改现有对象集，包括删除一些对象，并添加新对象。

这种通常用于规则引擎的方法与Command设计模式有一些相似之处，因为规则引擎通常用于对传递到规则引擎中的域对象执行一个或多个动作。与命令模式不同，规则引擎的设计使底层API无法知道在其上执行规则的对象和规则的结果。为了使用一组特定的规则，调用者将需要理解输入，并且可能需要对隐含效果有所了解。

如果规则引擎是Drools，则创建引号的过程可能遵循以下顺序：

在这种情况下，规则（由加载的RuleBase对象表示）被拉入有状态的上下文，如WorkingMemory对象表示。当前状态被声明到工作内存中，规则被触发，并且所有得到的报价被返回。相同的模式可以用于单报价系统（对于保险提供者）或多报价系统（对于经纪人）。

通过将规则引擎放在用于创建报价的服务外观后面，可以封装为此目的采用规则引擎的实现。用户界面，服务和数据访问方面的现有投资不需要修改。通过在数据收集应用程序和市场敏感规则之间建立关注点分离，它甚至可以使进入新市场更加容易，可以针对特定的报价服务对其进行多次更新，测试和重新部署。单一报价服务可以按区域，承销商等委托多个规则集之一。

这些关于在保险业中如何使用规则引擎的简单示例是众多选择之一。还有许多其他方法可以将规则引擎集成到您的应用程序中。最重要的是，这些示例将用作进一步讨论规则引擎使用中的模式和反模式的工作示例。

规则引擎模式和反模式

人们尝试应用规则引擎的方式有很多种。这些方式中的每一个都有权衡，并且可以某种方式告知您自己对规则引擎的使用。在大多数情况下，在您自己的环境中探索这些折衷的最佳方法是使用规则引擎并试验结果。

外部化业务逻辑

许多企业选择规则引擎作为从应用程序本身外部化业务规则的方法。这允许在与应用程序本身不同的生命周期中开发，测试和部署规则。这通常是为了支持更深层次的业务需求，例如对快速变化的支持，然后再解决。它可以允许更改应用程序的关键业务规则而无需重新编译和重新部署应用程序，并且可以建立关注点分离。

在我们的保险示例中，它可以允许在一个生命周期内开发数据收集，报价表示的大部分静态功能，同时可以开发由法规，市场和承保统计数据驱动的驱动创建保险报价的特定规则。在完全不同的生命周期中。

规则引擎是一种将业务规则外部化的可行方法，并且可以享受这些团队所寻求的好处。也就是说，确实可以通过其他方式实现这些相同的好处，因此，与其他方法相比，权衡此方法的好处很重要。

如果您唯一关心的是将业务规则的部署与应用程序分开，那么使用规则引擎可能不是实现此目的的最简单方法。业务规则的具体实现可以在运行时加载和重新加载。如果您担心避免显式的重新编译周期，请考虑使用脚本语言或动态重新编译技术（如Janino）。

与规则引擎相比，尽管规则引擎在其他领域有很多优势，但是与规则引擎相比，其中许多选项所需的时间，能源和许可成本更少。

变革的速度

在某些环境中，业务规则经常更改，甚至不断更改。一些团队寻求使用规则引擎来支持此类更改。

例如，通过从应用程序代码外部化业务规则，您可以使这些规则能够分别更改和部署，甚至可以进行热部署，如上一节所述。另外，某些规则引擎支持视觉设计或动态语言，可以支持快速开发方法。

由于保险法规和新的统计信息可能会导致必须在短时间内应用的报价发生变化，因此了解驱动创建规则的逻辑可以快速支持此类变化非常重要。

最终，规则引擎并不是支持变更的灵丹妙药，但它们可以提供帮助。尽管可以在有或没有规则引擎的情况下采用许多相同的方法，但是手动实施这些方法的成本效益可能不及使用特定规则引擎附带的工具那样。

就像在业务逻辑的外部化中一样，如果您仅关注变更的速度，那么您可能需要考虑快速开发工具和/或脚本语言，与规则引擎相比，它们可能需要更少的精力，时间和金钱。

无论使用哪种技术，都必须强调即使在（尤其是）快速变化的环境中，测试也是最重要的问题。在没有进行全面测试的情况下更改正在运行的应用程序中的复杂业务规则是灾难的根源。

业务用户制定业务规则

业务规则通常由业务人员定义，但是在大多数业务中，它们是由开发人员实施的。一些团队转向规则引擎来授权其业务用户在没有（或至少减少）开发人员支持的情况下制定规则。成功后，这将鼓励业务用户控制业务解决方案，参与其中并了解不可能或不可能的事情，只有在开发人员需要全新的功能时才求助于开发人员。

在这方面，规则引擎确实是一种改进，但是，即使是中等复杂度的大多数规则解决方案也需要开发人员的参与，这也是事实。即使工具支持非常易于使用，在考虑极端情况和极端情况时，也存在许多企业用户不需要开发的技术分析思路和严格性。

这个领域中最成功的解决方案可以在开发人员和业务用户之间实现某种协作，开发人员可以创建边界，建立宏大的结构并处理任何必要的技术复杂性，同时允许业务用户自定义业务规则中的各个业务规则的细节。更可控的环境。

对于汽车保险经纪人来说，雇用开发人员预先创建复杂的决策表的能力是一种有效的方法，该决策表可以针对特定市场进行配置，或者为更改提供支持，企业用户可以使用不同的经济参数进行配置。

在我们最近的一些项目中，我们已经能够使用Drools的“决策表”取得巨大的效果。 Java开发人员创建并增强了业务领域和将业务决策委托给规则的应用程序，并在多个Excel工作簿中创建了一系列决策表结构，这些结构构成了解决方案的边界。然后，业务分析部门的团队成员可以通过参数化这些表以实现业务目标来创建规则，如下所示：

这已经相当成功，并且经过多次工作之后，业务用户越来越多地寻求在开发人员的支持下创建决策表结构时承担更多的责任。

在寻找规则引擎来填充此规则时，重要的是要识别您希望创建或修改业务规则的业务用户，并让他们检查并最好使用这些工具来开发一些实际的方案，而不是简单地接受营销声明有关企业用户的适用性。或者，考虑使用一种具有适当评估期的产品，该评估期将允许您进行一些探索，然后再承诺使用您的业务用户发现他们不想使用的工具。

放弃流量控制

允许规则引擎确定要运行的规则以及何时运行，这是充分利用规则引擎的全部功能的重要步骤。习惯于控制其业务逻辑执行的开发人员可能会发现这种转换很麻烦，但是一旦您习惯了这种工作方式，您可能会发现它提供了相当多的功能。

许多规则引擎允许选择和排序规则的过程受到影响。 Drools提供了一系列冲突解决策略和规则属性，例如显性和议程组来控制它们。这些类型的选项使您可以将总体流程控制留给规则，但可以发挥实现业务逻辑或调整规则引擎采用的方法所需的一切控制。

规则作为程序代码

如果您已经完成了大量的过程编程，那么切换到面向规则的开发模型可能会有些混乱。您可能会陷入程序开发的熟悉的开发模式，并提出以下问题：

如何只运行一条规则？我可以按顺序列出要运行的规则吗？

重要的是要意识到可以做这些事情，但这并不总是明智的。例如，在Drools中，您可以使用激活过滤器来控制运行哪些规则，并可以使用冲突解决方案来控制顺序。抵制这些选择：有时候它们是必要的，但是一旦对旧的程序范例产生下意识的React，就很容易就可以很快地获得这些控制。

叉积

当组装事实以提供给规则引擎时，很容易忘记所涉及的组合，并且当少量的单个事实与少量的规则结合在一起时，组合的结果很快就会变得惊人地大。

如果保险规则针对两辆汽车和一位被保险客户，并且知识库由五千辆汽车和五千名车主组成，则引擎可能需要为五千辆车主中的每辆车考虑两千五百万辆汽车的组合，或者一百二十辆共50亿个组合。

如果您没有考虑要求规则引擎进行比较的规模，那么您可能会编写诸如此类的规则，并发现解决方案的性能与预期的不符。

因此，在开发规则解决方案时，一定要保持规模感；这可以通过限制传入和传出任何给定规则集的信息量，或者通过定期的性能和负载测试以持续建立和评估指标来实现。

组合与排列

如果一个规则采用一个特定类型的多个事实，则规则引擎可以提供这些事实的所有排列和组合。因此，如果知识库有三个驱动程序（Adam，Beth，Chris），并且规则需要其中两个，则规则引擎可能会使用以下人员组合执行该规则九次：（Adam，Adam），（Adam，Beth）），（亚当·克里斯），（伯斯·亚当），（伯斯·贝斯），（伯斯·克里斯），（克里斯·亚当），（克里斯·贝斯），（克里斯·克里斯）。

对于某些事实，这可能是理想的行为，但是在其他情况下，可能希望为您提供唯一的组合或没有重复的组合。这通常是在规则条件下执行的。

为了避免规则中出现重复项，只需添加一个条件，即第一个项与第二个项不相同，则删除以下元组：（Adam，Adam），（Beth，Beth），（Chris，Chris）并保留这六个：（亚当，贝丝），（亚当，克里斯），（贝斯，亚当），（贝斯，克里斯），（克里斯，亚当），（克里斯，贝斯）。

为了获得唯一的组合，您可以使用对象排序，例如要求第二个人的名字按字母顺序排列在第一人的名字之后，并删除以下元组：（Beth，Adam），（Chris，Adam），（Chris，Beth）并留下这三个：（亚当·贝丝），（亚当·克里斯），（贝斯·克里斯）。甚至可以使用Java中对象的哈希码执行此操作。

一些规则引擎具有为您减少这些组合和排列的功能，因此了解规则引擎的功能及其如何提供这些组合非常重要。 Drools 2提供了所有这些组合。至少在RC2化身中，Drools 3使用身份过滤器删除重复项。

递归

与使用软件进行任何形式的流控制一样，自递归可能是一个问题。例如，如果规则修改了事实基础，该更改是否会使规则再次运行，从而导致无限循环？

或者，您可以创建一个规则循环，一个规则触发另一个规则，最终导致再次触发第一个规则。如果您在规则设计中不阻止它们，则可能会发生此类循环。

有一些解决方案-在某些情况下，只要注意一点，在定义规则时就不要触发它。在这种情况下，Drools具有“无循环”属性。在许多情况下，最好的解决方案是确保规则的设计不会触发自己。

例如，如果您使用规则将折扣应用于保险报价，则可以简单地制定规则的条件之一，即报价没有指定折扣。这不仅意味着折扣规则不会触发自身，而且还允许您具有折扣规则层次结构的可能性，一般情况下优先级最低，它们可以干净地交互。

当您花了足够的时间为规则引擎开发规则时，这些类型的设计决策就会变得很自然，但是如果您的经验是过程或面向对象的代码，这些设计决策就不会立即变得显而易见。

粒度

首次使用规则引擎时，很容易使用规则的粒度以及驱动它们的数据返回典型的编程范例，例如：

编写大型复杂的规则，以在规则而不是规则引擎内移动流控制。向规则引擎提供大的对象图，在规则本身中导航对象图，而不是使用细粒度的事实，并允许规则引擎选择适当的事实。

这些方法使您可以更快地将规则引擎集成到现有应用程序中，并控制采用新技术所面临的风险。但是，它们也限制了规则解决方案的功能。赋予规则引擎更大的自由度是从实现中获得更多价值的最佳方法。为了放松对规则引擎的控制：

创建小的，细粒度的简单规则。向规则提供细粒度，简单事实。

这些规则更容易启用和禁用。可以容易地组合和重组；可以通过规则引擎中的冲突解决进行重新排序，并且即使对于非开发人员也易于理解和编写。但是，当将它们作为规则集一起应用时，结果可能会非常复杂。

以Drools的Java / XML规则为基础，请考虑以下示例：

package com.insurance.auto

import com.insurance.auto.Driver

import com.insurance.auto.Policy

import com.insurance.auto.Percentage

rule "Age Rule"

when

$p: Policy ( declined == false )

then

Driver driver = $p.getPrimaryDriver();

if( driver.getAge() < 25 || driver.getAge() > 60 )

$p.increasePremium( new Percentage( 50 ) );

else if( driver.getAge() <= 60 && driver.getAge() < 40 )

$p.discountPremium( new Percentage( 20 ) );

else

在这种情况下，结果包含条件逻辑，通常表明有多个规则是可取的。同样，通过依靠从策略到驱动程序的域对象导航，很难编写需要驱动程序但不需要策略的规则。

该规则可以重新编写为以下形式的几个规则：

package com.insurance.auto

import com.insurance.auto.Driver

import com.insurance.auto.Policy

import com.insurance.auto.Percentage

rule "Young Premium"

when

$d: Driver ( age < 25 )

$p: Policy ( declined == false, $pd:primaryDriver -> ($pd==$d) )

then

$p.increasePremium( new Percentage( 50 ) );

end

这些规则更简单，更容易编写和理解，并使用以较少关联的方式处理的事实。

综上所述

规则引擎是一个有用的工具，可用于外部化业务逻辑，允许业务用户编写规则或以有效方式解决某些类型的问题。与其他方法相比，需要权衡取舍，因此以系统的方式进行此决策很重要：

了解您要解决的问题，要解决的问题研究常规规则引擎还是特定规则引擎将帮助您实现这些目标

通常，如果需要外部化业务规则，支持快速更改并授权业务用户更改业务规则，则可以考虑使用业务规则解决方案。如果您通过放弃流控制，使用细粒度的规则和对象，避免产生叉积以及理解规则方法可以创建的组合和递归来接受新的范例，那么您将充分利用规则引擎。

如果经过考虑后，您不确定规则引擎能否满足您的需求，请考虑使用免费的规则引擎（如Drools）开发低成本的概念验证，并自行评估规则引擎是否适合您的问题空间。

如果您决定采用规则引擎作为解决方案的一部分，请接受规则引擎需要一些新的设计和开发技能，并期望一些增加的开发成本和失误，直到您的团队掌握了这些技能。

侧边栏：其他规则引擎

尽管我们已经使用Drools作为本文的示例规则引擎，但是还有其他一些开源和商业的规则引擎。其中的详尽列表以及它们如何进行比较超出了本文的范围，但是这里提供了一些更常见替代方法的一些指针：

商务对话烈焰顾问杰西焦耳开放规则规则规则力量

这些规则引擎中有许多，特别是商业规则引擎，提供的功能，服务，模块，组件和工具比我们在此处详细描述的功能要多。选择规则引擎时，您可能需要考虑以下事项：

增强业务用户和开发人员能力以及两者之间协作的工具规则创作工具：基于Web，基于桌面，与开发人员和业务用户工具（例如Eclipse或Excel）集成规则测试工具：测试，模拟，错误检查和调试，依赖性检查规则算法和性能规则编辑，审核和批准的工作流，带有版本控制的规则管理存储库与现有软件和构建架构集成运营支持：监控，审计培训与支持