最近，我正在阅读 JBOSS Drools 手册 [ref - 2.2.5. 强耦合和松耦合]。下面是它的摘录“如果你的规则都是强耦合的，那么这些规则可能会在未来变得不灵活，更重要的是，规则引擎可能是矫枉过正的（因为逻辑是一个清晰的规则链 - 并且可以被硬编码。[决策树可能是有序的]）。这并不是说强耦合或弱耦合本质上是不好的，但在考虑规则引擎以及如何捕获规则时要牢记这一点。“松散”耦合的规则应该产生一个允许更改、删除和添加规则的系统，而无需更改其他不相关的规则。
这是否意味着，规则引擎不适合实现复杂的业务逻辑[紧耦合规则或规则链]。
在我目前的项目中，我们有一系列规则，即一条规则的结果决定另一条规则的结果，依此类推。应用程序有许多内部变量来链接规则。我认为规则引擎可能有助于通过声明性规则和动态业务逻辑的附加优势来处理复杂性。
这方面的讨论会有所帮助......
即使您确切地知道需要执行的测试的顺序和性质以及应该执行的操作，某些逻辑也不是那么容易正确。例如公司审计、援助计划的经济状况测试、保险法规等。
今天的大多数规则引擎都开始包含一个决策表功能，它实际上引入了一些“有限的强耦合”（我不知道这是否真的是一个术语，但它是我理解在 ILog 等系统中的效果的方式，流口水等）。这很有帮助，因为某些测试仅与其他测试相关，并且决策表对于构建这些测试比 IF THEN ELSE 结构要好得多。
Corticon（专有规则引擎）和 DTRules（开源规则引擎）只是抛弃了整个松散耦合的规则方法，只是构建决策表。这个想法是，对于许多应用程序来说，为构建决策提供一个很好的结构（相当于所有事物下的决策树）更容易。
“避免强耦合”与“避免复杂性”无关。
文档提倡的是，你不应该从另一个规则中调用一个规则，相反，每个规则都应该产生一个结果，结果本身应该触发链中的下一个规则。这种方式规则不关心接下来会发生什么，而是处理事实（啊哈！）。如果——而不是为事实编写规则——你专注于编写一个普通的程序逻辑流，你就不需要规则引擎的额外复杂性。
区别是微妙的，但并不比“不要将您的业务逻辑放在视图中”或“不要将您的数据库访问代码放在您的业务逻辑中”之类的规则更微妙。
在 IBM ILOG Jrules 中，您可以通过多种方式来表示您的规则。
因此您可以决定哪种方式可以使用上述三种方式来将您的复杂规则破解为更简单的形式。
您可以使用带有条件流的规则流编排来解决“一条规则的结果将是另一条规则的输入”
我认为这完全取决于 UI，而不是规则包含的实际逻辑。请记住，当今的大多数引擎都是基于决策表的。所有这些“强耦合和松耦合”只不过是作为糟糕 UI 或缺乏 UI 的借口的流行词。普通引擎可以处理任何复杂规则的执行。请注意，这是我的个人观点，很多人会完全不同意。所以，请不要急于降低我的答案，我只是想帮忙:)
典型的概念是，具有复杂逻辑的规则看起来真的“一团糟”，甚至不可能在决策表中实现。通常，人们试图通过将复杂规则划分为更小的简单规则并根据执行优先级将它们堆叠成规则集来解决这个问题。
通过实现括号而不是优先级，有一些新引擎具有无决策表 UI。括号也有助于复杂性。