rule-engine - 什么时候不应该使用规则引擎？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭10 年前。

Improve this question

我有一个相当不错的使用规则引擎的优点列表，以及使用它们的一些原因，我需要的是一个不应该使用规则引擎的原因列表

到目前为止我所拥有的最好的是:

Rules engines are not really intended to handle workflow or process executions nor are workflow engines or process management tools designed to do rules.

还有其他不应该使用它们的重要原因吗？

Answer 1

我将给出两个来自个人经验的例子，其中使用规则引擎是一个坏主意，也许这会有所帮助:-

1. 在过去的一个项目中，我注意到规则文件(该项目使用了Drools)包含大量java代码，包括循环、函数等。它们本质上是伪装成规则文件的java文件。当我向架构师询问他的设计理由时，我被告知“这些规则从来就不是为了让业务用户维护的”。

教训:它们被称为“业务规则”是有原因的，当您无法设计一个可以被业务用户轻松维护/理解的系统时，不要使用规则。

另一个案例；该项目使用规则是因为需求定义/理解不明确并且经常更改。开发团队的解决方案是广泛使用规则来避免频繁的代码部署。

教训:在初始版本更改期间，需求往往会发生很大变化，并且不保证规则的使用。当您的业务经常变化(而不是需求)时使用规则。例如:- 随着税法的变化，处理税款的软件每年都会发生变化，并且规则的使用是一个好主意。随着用户确定新的需求，Web 应用程序的 1.0 版本会经常发生变化，但会随着时间的推移而稳定下来。不要使用规则作为代码部署的替代方法。​