使用 Drools 规则引擎实现业务逻辑

核心提示： 下列假设为应用程序解决的虚构问题设置了场景：名为 XYZ 的公司构建两种类型的计算机机器：Type1 和 Type2，机器类型按其架构定义，使用 Drools 规则引擎实现业务逻辑(3)，XYZ 计算机可以提供多种功能，当前定义了四种功能：DDNS Server、DNS Server、Gatew

下列假设为应用程序解决的虚构问题设置了场景：

名为 XYZ 的公司构建两种类型的计算机机器：Type1 和 Type2。机器类型按其架构定义。

XYZ 计算机可以提供多种功能。当前定义了四种功能：DDNS Server、DNS Server、Gateway 和 Router。

在发运每台机器之前，XYZ 在其上执行多个测试。

在每台机器上执行的测试取决于每台机器的类型和功能。目前，定义了五种测试：Test1、Test2、Test3、Test4 和 Test5。

当将测试分配给一台计算机时，也将测试到期日期 分配给该机器。分配给计算机的测试不能晚于该到期日期执行。到期日期值取决于分配给机器的测试。

XYZ 使用可以确定机器类型和功能的内部开发的软件应用程序，自动化了执行测试时的大部分过程。然后，基于这些属性，应用程序确定要执行的测试及其到期日期。

目前，为计算机分配测试和测试到期日期的逻辑是该应用程序的已编译代码的一部分。包含该逻辑的组件用 Java 语言编写。

分配测试和到期日期的逻辑一个月更改多次。当开发人员需要使用 Java 代码实现该逻辑时，必须经历一个冗长乏味的过程。

何时使用规则引擎？

并非所有应用程序都应使用规则引擎。如果业务逻辑代码包括很多 if-else 语句，则应考虑使用一个规则引擎。维护复杂的 Boolean 逻辑可能是非常困难的任务，而规则引擎可以帮助您组织该逻辑。当您可以使用声明方法而非命令编程语言表达逻辑时，变化引入错误的可能性会大大降低。

如果代码变化可能导致大量的财政损失，则也应考虑规则引擎。许多组织在将已编译代码部署到托管环境中时具有严格的规则。例如，如果需要修改 Java 类中的逻辑，在更改进入生产环境之前，将会经历一个冗长乏味的过程：