规则引擎 - 优点和缺点?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (530)

我正在审核一个使用所谓的规则引擎的项目。简而言之,它是从应用程序代码中外化业务逻辑的一种方法。

这个概念对我来说是全新的,我对此非常怀疑。我在质疑规则引擎方法。对我来说,他们似乎是减弱域模型的好方法。例如,我正在做一个java webapp与一个规则引擎交互。然后我决定我想要一个基于相同域的Android应用程序。除非我想让Android应用程序与规则引擎进行交互,否则我将不得不错过已写入的任何业务逻辑。

由于我还没有任何经验,只是好奇心,我有兴趣了解有关使用规则引擎的优点和缺点吗?我能想到的唯一一个专业人员是,你不需要重新构建整个应用程序来改变一些业务规则。

提问于
用户回答回答于

我所看到的大多数规则引擎都被系统代码视为黑盒子。如果我要构建一个领域模型,我可能会希望某些业务规则是领域模型的内在属性,例如,业务规则告诉我何时对象具有无效值。这允许多个系统共享域模型而不需要复制业务逻辑。我可以让每个系统使用相同的规则服务来验证我的域模型,但这似乎削弱了我的域模型(正如问题中指出的那样)。为什么?因为我始终依靠系统程序员来决定何时应该执行业务规则,而不是始终在所有系统上始终执行业务规则。这可能不是一个问题,如果领域模型来到你完全填充,但可能会有问题,如果你还有另一类业务规则:决策制定。例如,一家保险公司可能需要对承保申请人的风险进行分类并收取保费。你可以将这些类型的业务规则放置在你的域模型中,但对于这种场景的集中决策通常是可取的,实际上,它们非常适合面向服务的体系结构。这确实讨论了为什么使用规则引擎而不是系统代码。规则引擎可能是更好的选择的地方是负责决策的业务规则随着时间的推移而变化(正如其他一些答案指出的那样)。

关于模板的另一个注意事项:模板永远不会比编写没有模板的规则花费更少的时间,因为模板必须至少描述规则。计划一个更高的初始成本 - ROI是因为你节省了将来维护的系统代码。

用户回答回答于

我已经看到了在我工作的生产环境中运行的着名的商业Rete规则引擎的两个应用程序。我会考虑一个成功,另一个失败。

成功的应用程序是一个决策树应用程序,由约10棵树组成,每棵树约30个分支点。规则引擎有一个用户界面,可以让业务人员维护规则。

不太成功的应用程序有〜3000条规则抨击规则数据库。当添加新规则时,没有人知道是否存在冲突规则。对Rete算法有一点了解,并且产品的专业知识已经离开了公司,所以它变成了一个不可触及和不可修复的黑盒子。部署周期仍受规则更改的影响 - 必须在更改规则时完成完整的回归测试。记忆也是一个问题。

我发现使用对象作为划分规则引擎空间的方法没有任何问题。在遵循私有规则引擎的对象中嵌入行为对我来说似乎没有问题。当规则引擎要求状态不是其对象的一部分才能正常触发时,问题会触及你。但这只是设计难度的另一个例子。

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励