使用Rule Engine实现规则链[复杂的业务逻辑]是否过度杀伤？

Question

最近，我正在阅读JBOSS Drools手册中的规则引擎[参考 - 2.2.5。强而松散的耦合]。下面是它的摘录'如果你的规则都是强耦合的，那么规则可能具有未来的不灵活性，更重要的是，规则引擎可能是过度的（因为逻辑是一个明确的规则链 - 并且可以硬编码。[决策树可以按顺序]）。这并不是说强耦合或弱耦合本质上是坏的，但在考虑规则引擎和如何捕获规则时要记住这一点。 “松散”耦合的规则应该导致系统允许更改，删除和添加规则，而无需更改其他不相关的规则。'

这是否意味着，规则引擎不适合实现复杂的业务逻辑[紧密耦合的规则或规则链]。

在我目前的项目中，我们有一系列规则，即1条规则的结果决定另一条规则的结果，依此类推。该应用程序有许多内部变量来链接规则。我认为规则引擎可以通过声明规则和动态业务逻辑的附加优势来帮助处理复杂性。

这方面的讨论会有所帮助......

Answer 1

即使您确切地知道需要执行的测试的顺序和性质，以及应该产生的操作，某些逻辑也不容易正确。例如，企业审计，援助计划的手段测试，保险法规等。

今天的大多数规则引擎都开始包含一个决策表功能，它实际上引入了一些“有限的强耦合”（我不知道这是否真的是一个术语，但它是我如何理解系统中的效果如ILog，Drools等）。这很有用，因为有些测试只与其他测试有关，而决策表比IF THEN ELSE结构更好地构建这些测试。

Corticon（专有的规则引擎）和DTRules（开源规则引擎）只是抛弃了整个松散耦合的规则方法，只需构建决策表。我们的想法是，为许多应用程序提供一个很好的结构来构建您的决策（相当于所有内容下的决策树）。

Answer 2

“避免强耦合”与“避免复杂性”无关。

文档提倡的是你不应该从另一个规则中调用一个规则，相反，每个规则应该产生一个结果，结果本身应该触发链中的下一个规则。这种方式规则不关心接下来会发生什么，而是处理事实（啊哈！）。如果 - 而不是编写事实规则 - 你专注于编写一个普通的程序逻辑流程，你真的不需要增加规则引擎的复杂性。

差别很微妙，但并不比“不要将业务逻辑放在视野中”或“不将数据库访问代码放入业务逻辑”这样的规则更微妙。

Answer 3

在IBM ILOG Jrules中，有许多方法可以表示您的规则。

1. 用简单的英语语言，如果有其他语法。
2. 决策表 - 用于一组值
3. 决策树 - 多个结果，分支出来。

因此，您可以决定使用上述哪种方式将您的复杂规则破解为更简单的形式。

您可以使用带条件流的规则流程编排来解决“1规则的结果将是另一条规则的输入”

Answer 4

我认为这完全取决于UI，而不是规则所包含的实际逻辑。请记住，今天的大多数引擎都是基于决策表的心态。所有那些“强大而松散的耦合”只不过是用来作为一个糟糕的用户界面或缺乏它的借口的流行语。普通引擎可以处理任何复杂规则的执行。请注意，这是我个人的观点，很多人都会完全不同意。所以，请不要急于降级我的答案，我只是想帮助：）

典型的概念是具有复杂逻辑的规则看起来真的“搞砸了”甚至不可能在决策表中实现。通常情况下，人们会尝试通过将复杂的规则划分为更小的简单规则来对抗这种情况，并根据执行优先级将它们叠加到规则集中。

通过实现括号而不是优先级，有新的引擎具有无决策表的UI。括号也有助于提高复杂性。