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

核心提示： 必须重新编译应用程序代码，在测试中转环境中删除代码，使用 Drools 规则引擎实现业务逻辑(4)，由数据质量审核员检查代码，由托管环境架构师批准更改，则应执行 Test4 和 Test5，如果计算机是 Type2 且其中一个功能为 DDNS Server，计划代码部署，即使对一行代码的简单更改

必须重新编译应用程序代码。

在测试中转环境中删除代码。

由数据质量审核员检查代码。

由托管环境架构师批准更改。

计划代码部署。

即使对一行代码的简单更改也可能花费组织的几千美元。如果需要遵循这些严格规则并且发现您频繁更改业务逻辑代码，则非常有必要考虑使用规则引擎。

对客户的了解也是该决策的一个因素。尽管您使用的是一个简单的需求集合，只需 Java 代码中的简单实现，但是您可能从上一个项目得知，您的客户具有在开发周期期间甚至部署之后添加和更改业务逻辑需求的倾向（以及财政和政治资源）。如果从一开始就选择使用规则引擎，您可能会过得舒服一些。

因为在对为计算机分配测试和到期日期的逻辑进行更改时，公司会发生高额成本，所以 XYZ 主管已经要求软件工程师寻找一种灵活的方法，用最少的代价将对业务规则的更改 “推” 至生产环境。于是 Drools 走上舞台了。工程师决定，如果它们使用规则引擎来表达确定哪些测试应该执行的规则，则可以节省更多时间和精力。他们将只需要更改规则文件的内容，然后在生产环境中替换该文件。对于他们来说，这比更改已编译代码并在将已编译代码部署到生产环境中时进行由组织强制的冗长过程要简单省时得多（参阅侧栏 何时使用规则引擎？）。

目前，在为机器分配测试和到期日期时必须遵循以下业务规则：

如果计算机是 Type1，则只能在其上执行 Test1、Test2 和 Test5。

如果计算机是 Type2 且其中一个功能为 DNS Server，则应执行 Test4 和 Test5。

如果计算机是 Type2 且其中一个功能为 DDNS Server，则应执行 Test2 和 Test3。