Drools——我们何时应该使用规则

最新推荐文章于 2024-08-16 20:16:30 发布

哎孩

最新推荐文章于 2024-08-16 20:16:30 发布

阅读量884

点赞数

分类专栏：规则引擎 drools 文章标签： drools

规则引擎同时被 2 个专栏收录

5 篇文章 1 订阅

订阅专栏

drools

3 篇文章 0 订阅

订阅专栏

何时使用规则引擎

规则引擎是一个非常强大的组件。在我们定义规则逻辑的时候，它为我们提供了大量的变化。它允许我们可以在非常短的时间内完成对我们系统复杂度、性能和稳定性的处理。

这些改进对一些系统是很有用的，业务规则可以在你发现的一些类型的系统里进行实现和添加。尽管如此，我们还是想备注下在技术栈中引入业务规则会带来更多好处的系统。这些项目具有以下一个或几个特征：

它们定义了非常复杂的场景，甚至连业务专家都无法满足
没有开源的或容易编写的算法解决
需求容易变且经常更新
基于一定量的数据进行快速决策

复杂的场景、简单的规则

随着我们不断的研究，每隔一段时间，我们就发现系统或者系统的一部分组件之间的小关系就开始越重要。起初，它们看起来大概是个无害的组建，它们基于两三个数据源之间的小关系来做一些小决策。未来随着我们开始对它深入研究，这些关系越来越重要。最终，我们可能发现这些关系之间会产生更多集体性行为，甚至连业务专家都没注意到这种行为会发生的，但是这种行为又是有意义的。这种系统我们称之为复杂系统，业务规则可以给这种系统提供更多的帮助。

复杂场景往往都是由小陈述定义的。从全局来看，涉及到每个完成定义场景所需要的组合、聚合和数据的抽象，通常都在我们最初掌握的东西之外。因此，这些系统是通过部分解释开始定义的。系统中每个小关系都被定义为不同的需求。当我们分析这些需求的时候，将其分解为最基本的节点，我们就会发现我们自己需要定义的规则。

每个业务规则都可以帮助定义复杂场景中的每个小组件。随着越来越多的规则添加到系统中，它们之间越来越多的关系可以使用简单遗易读的方式处理。当执行复杂场景的时候，每个规则会成为系统做的每个小决策的自解释手册。复杂应用的例子有很多，正如下面所述：

欺诈检测系统：通常它们会从中央服务器中拿到每个完成订单的交易，并深入调查它们之间的相关行，以确定订单来自非诚实合法使用系统的情况。比如说异常的信号卡操作、稳定的账户中存在大量的活动、交易中存在非法的参数等通常都是这类系统要寻找的。
自定义回头客零售优惠券：在各种商业活动中，客户的忠诚度是非常重要的。常用的策略是基于客户的购物习惯对指定的优惠券设置最大数量。为了可以发正确的券，一个复杂的系统需要评估客户的购买记录，将用户框在指定的统计组里，并为组选择最好的选择。这些所有的事情需要基于他们的购买记录和购买趋势的复杂关系来完成。
信用评分系统：信用评分是基于的个人信用文件的级别去表示用户信用价值的数学表达式。每个债务、信贷、购买或者关系都可以成为有效的数据来源，都决定着个人的信用。这个场景的复杂度来源于，必须基于所有的数据来源的相关性来关联、衡量和返回出指定的分数

不断变化的场景

当我们不需要处理复杂的场景，我们只是想通过业务规则来更好的处理程序的逻辑。如果在做一部分决策的时候所涉及的元素变化趋于频繁，业务规则可以成为一个良好的管理易变的系统行为的解决方法。

业务规则在规则引擎中表现为一个数据树。与修改列表中元素的方式相同，我们可以从规则引擎中添加和移除规则。它可以在无需重启应用和重新安装任何组件的完成。Drools6框架提供了通过外部资源自动更新规则定义的内部方式。Drools6框架也准备提供对用户好友的编辑工具进行更新规则的方式。Drools6的api完整框架是基于让其尽可能的自适应。

如果你发现一个系统的需求变化非常频繁，甚至每天或每小时都在发生变化。由于规则引擎的更新能力，业务规则非常适合这种需求的系统，而不管系统的复杂度如何。

示例-eShop系统

这本书的其他部分，我们会致力于基于相同领域的规则组成的决策服务的集合：eShop应用。实践是学习新框架的关键部分，为了更简单，也为了尽可能快的了解规则引擎的详情，我们将会定义可以在大多数例子中共享的模型。

开始之前，我们将会定义eShop系统的模型。这些模型将会包括我们应用制定决策时相关的不同的事情。下面表示的就是这些模型：

产品：我们的系统将会卖不同种类的商品。每种商品都将会以产品对象存在，而且包含指定商品的详情。
库存：每种产品存储的数量。
供应商：每中产品都来自不同的供应商。他们每个人通过不同的交货方式为eShop提供特定类型的商品。
供应商请求：当产品过少或超卖时，我们将会向供应商创建供应商请求以充实库存。
客户：eShop中对特定商品有特殊偏好的人，正在或已完成订单，特定的人物统计信息（标签）、支付偏好（支付首选项）和其他可以从eShop中获得的偏好的数据。
订单：当一个客户喜欢eShop中的一个或者多个产品时，他们会商品进行下单交付。依赖于用户是否已经成功收到商品，订单有不同的状态。订单中还有订单中商品的数量信息。
优惠：eShop提供了不同类型的优惠，具体取决于购买类型。
售卖渠道：eShop会与多个网站合作，它们每个作为不同的售卖渠道。每个售卖渠道都有其特定的目标受众，这是由使用它的用户决定的。

因为我们需要更多类型的对象去定义eShop中的现实实体，我们会定义更多的类来扩展对我们世界的了解。一旦我们将所有领域数据关联在一起，我们将能检测所有类型的情况，并且可以做出最有利于eShop和客户的行为。如下所示，这些是我们将可以做的事情：

通过将产品和售卖渠道关联然后对比其他渠道，给特定种类的商品定义最好的售卖渠道。基于这些信息，我们可以为产品在这些渠道创建自定义优惠。
为特定的产品定义客户偏好，基于这些信息，我们可以针对不同的口味为它们提供优惠券。
确定指定产品的平均消耗，然后跟其库存进行对比。如果可能，我们可以自动触发供应商请求。
基于我们为供应商提供的订单数量，我们可以要求优惠价格。
我们可以分析客户在我们系统不同的购买记录。如果在某些时候，购买记录超过我们认为的正常范围，我们可以做一些行动，从简单的警告到为特定的购买记录提供人员支持（客服人员介入）。

这些只是我们通过这些领域的业务规则做的事情。当我们发现有很多情况来满足特定的需求时，我们将会学习到更多关于编写规则和配置运行时环境的技术。为了充分利用Drools6框架，每个新的必需技术都会指导我们定义新的组件。

何时不使用规则引擎

每个工程都会或多或少的从使用业务规则中受益。它是高效率、容易改变和自解释性的软件组件。但是，一个工程大概有一个条件分组，这会让业务规则太具备杀伤力。从业务规则获取收益更少的工程有如下所示的特征：

工程中涉及很少的规则：如果在需求收集中确定的业务规则非常简单，最多只会跨越一两个对象，那我们就没必要使用规则引擎。一个好的经验法则是如果我们写的规则代码需要至少一页的伪代码至少有两个嵌套的if-then，在这种情况下，我们大概是不需要规则引擎的。

业务规则不经常变化：如果不需要在运行期修改规则但是逻辑复杂，这时候使用规则引擎应该是一个好主意。但是，如果规则背后的复杂性没那么高，而且我们假设它会保持很久这种状态，我们大概不需要使用规则引擎。
对于应用程序来说，非常严格控制的执行流程至关重要：正如我们之前描述的，当执行我们的业务规则时，无法控制程序流。如果规则背后的业务逻辑依赖非常严格的按顺序执行的步骤集，业务规则大概不适合这种。但是如果它变化的非常频繁，大概值得考虑下业务流。

是否适合使用业务规则，一直是工程团队需要决定的责任，即使所有的条件都满足。毕竟，我们的经验可以让我们思考，将来规则的数量有大量的增长或者可能出现规则最终需要频繁的改变的场景。每个工程都有不同的特征，如果没有这些特征，将来无法考量一些现在不需要业务规则的工程。