首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >规则引擎-正反两面

规则引擎-正反两面
EN

Stack Overflow用户
提问于 2008-10-30 14:42:52
回答 8查看 40.2K关注 0票数 76

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

这个概念对我来说是全新的,我对此持怀疑态度。在过去几年里听到人们谈论Anemic Domain Models之后,我开始质疑规则引擎的方法。对我来说,它们似乎是弱化域模型的一个很好的方法。例如,假设我正在做一个与规则引擎交互的java webapp。然后我决定我想有一个基于相同域名的Android应用程序。除非我希望Android应用程序也与规则引擎交互,否则我将不得不错过已经编写的任何业务逻辑。

由于我还没有任何使用规则引擎的经验,只是出于好奇,我很有兴趣知道使用规则引擎的优缺点?我能想到的唯一优势是,你不需要仅仅为了改变一些业务规则而重建整个应用程序(但说真的,有多少应用程序真的有这么多改变呢?)但在我看来,使用规则引擎来解决这个问题就像是把创可贴贴在猎枪的伤口上。

更新-自从写了这篇文章,神自己,马丁福勒,就有了blogged about using a Rules engine

EN

回答 8

Stack Overflow用户

回答已采纳

发布于 2008-10-31 18:07:50

我见过的大多数规则引擎都被系统代码视为黑盒。如果我要构建一个域模型,我可能希望某些业务规则是该域模型的固有规则,例如,当对象具有无效值时告诉我的业务规则。这允许多个系统在不复制业务逻辑的情况下共享域模型。我可以让每个系统使用相同的规则服务来验证域模型,但这似乎会削弱我的域模型(正如问题中所指出的)。为什么?因为我并不是一直在所有系统上一致地实施我的业务规则,而是依靠系统程序员来确定何时应该实施业务规则(通过调用规则服务)。如果域模型完全填充,这可能不是问题,但如果您处理的用户界面或系统在其生命周期中更改域模型中的值,则可能会出现问题。

还有另一类业务规则:决策制定。例如,保险公司可能需要对承保申请人的风险进行分类,并得出保费。您可以将这些类型的业务规则放在您的域模型中,但是通常需要针对此类场景的集中式决策,而且实际上,它非常适合面向服务的体系结构。这确实提出了一个问题,为什么是规则引擎而不是系统代码。规则引擎可能是更好的选择,因为业务规则负责决策随着时间的推移而变化(正如其他一些答案所指出的那样)。

规则引擎通常允许您在不重新启动系统或部署新的可执行代码的情况下更改规则(无论您从供应商那里得到了什么承诺,请确保您在非生产环境中测试您的更改,因为即使规则引擎是完美的,人类仍然会更改规则)。如果您在想,“我可以通过使用数据库存储更改的值来做到这一点”,那么您是对的。规则引擎不是做新事情的魔盒。它旨在成为一个提供更高抽象级别的工具,这样您就可以更少地专注于重新发明轮子。许多供应商更进一步,允许您创建模板,以便业务用户可以填写空白,而不是学习规则语言。

关于模板的一个告别警告:模板永远不会比编写没有模板的规则花费的时间更少,因为模板必须至少描述规则。计划更高的初始成本(就像您要构建一个使用数据库存储更改的值的系统,而不是直接在系统代码中写入规则一样)- ROI是因为您节省了将来对系统代码的维护。

票数 40
EN

Stack Overflow用户

发布于 2008-12-29 19:20:29

我认为您对贫血域模型的担忧是合理的。

我见过在我工作的生产环境中运行的两个著名商业Rete规则引擎的应用程序。我认为其中一个是成功的,另一个是失败的。

成功的应用程序是一个决策树应用程序,由大约10棵树组成,每棵树有大约30个分支点。规则引擎有一个允许业务人员维护规则的UI。

不太成功的应用程序有大约3000条规则被添加到规则数据库中。没有人知道添加新规则时是否存在冲突规则。人们对Rete算法知之甚少,而且该产品的专业知识已经离开了公司,因此它成了一个不可触及和不可重构的黑匣子。部署周期仍然受规则更改的影响-当规则更改时,必须执行完整的回归测试。记忆力也是一个问题。

我会轻装上阵。当规则集的大小适中时,就很容易理解更改,比如上面给出的简单的电子邮件示例。一旦规则的数量攀升到数百条,我认为您可能会遇到问题。

我还担心规则引擎会成为应用程序中的单例瓶颈。

我不认为使用对象作为划分规则引擎空间的一种方式有什么错。在遵循私有规则引擎的对象中嵌入行为对我来说似乎没问题。当规则引擎需要的状态不是其对象的一部分才能正确触发时,问题就会出现。但这只是设计困难的另一个例子。

票数 29
EN

Stack Overflow用户

发布于 2008-10-30 15:03:42

在某些情况下,规则引擎可以提供很多价值。

首先,许多规则引擎以更具声明性的方式工作。一个非常粗糙的例子是AWK,您可以将正则表达式分配给代码块。当文件扫描器看到正则表达式时,将执行该代码块。

您可以看到,在这种情况下,如果您有一个很大的AWK文件,并且您想要添加另一个“规则”,您可以很容易地转到文件的底部,添加您的正则表达式和逻辑,并完成它。具体地说,对于许多应用程序,您并不特别关心其他规则在做什么,并且这些规则并不真正相互操作。

因此,AWK文件变得更像“规则汤”。这种“规则汤”的性质让人们非常专注于他们的领域,而几乎不关心系统中可能存在的所有其他规则。

例如,Frank对总额超过1000美元的订单感兴趣,因此他将感兴趣的规则系统放入其中。“如果order.total > 1000,那么给弗兰克发邮件”。

同时,萨利想要所有来自西海岸的订单:"IF order.source == 'WEST_COAST‘THEN email Sally“。

因此,您可以在这个微不足道的人为设计的案例中看到,一个订单可以满足两个规则,但两个规则彼此独立。西海岸1200美元的订单通知了弗兰克和萨利。当弗兰克不再担心的时候,他会干脆把他的规则从汤里拉出来。

在许多情况下,这种灵活性可能非常强大。它也可以像本例一样,以简单的规则向最终用户公开。使用高级表达式,也许还可以使用轻量级脚本。

现在,很明显,在一个复杂的系统中,可能会发生各种各样的相互关系,这就是为什么整个系统不是“用规则完成的”。有人,某处将负责规则,而不是失控。但这并不一定会降低这样一个系统所能提供的价值。

请注意,这甚至不适用于专家系统,在专家系统中,规则在规则可以创建的数据上触发,而是一个更简单的规则系统。

无论如何,我希望这个例子展示了规则系统如何帮助扩充一个更大的应用程序。

票数 26
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/250403

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档