如果将来需求会发生变化，将业务规则从代码中拉到自定义规则引擎中是个好主意吗？

Question

我们有一个要求，根据一些限制，需要向用户提供不同的事实。

类似的假设示例

If User belongs to Australia and earns more than 10k$ then show XYZ view of data/facts
If User belongs to USA and earns less than 5k$ then show ABC view of data/facts
...
...

现在我们可以，将此映射保留在用户模型中，并将这些业务规则包含在代码中要么我们可以将这些规则提取到JSON或DSL中，在其中可以简单地更改规则，而不必为每次更改都部署代码。

我们不知道这些规则将多久更改一次。

我已经阅读了支持和反对自定义迷你规则引擎的观点。

自变量：

1. Every small change will not require a deployment
2. All the rules related to this specific functionality are at one place (probably) making it easier to get an overview

反对：

1. (Martin Fowler article) It will become difficult to reason about your code
2. Anemic Data model anti-pattern
3. Over time it will be difficult to manage these rules
4. Conflicts between rules or the chance of some facts not belonging to any of the rules

Answer 1

通常，这取决于您的用例。查看您提供的示例，它看起来像是规则引擎的出色应用。通过外部化该逻辑，您将使您的应用程序更具声明性，易于维护，并更快地为用户提供价值。

在您的情况下，这是关键声明：

我们不知道这些规则将多久更改一次。

这表明您确实需要将该逻辑外部化到您选择的规则引擎或DSL。如果您不这样做，则每次这些规则确实发生更改时，您都将注册以部署新代码。

您撰写的示例是ProductionRules的非常经典的示例https://martinfowler.com/dslCatalog/productionRule.htmlhttps://en.wikipedia.org/wiki/Production_system_(computer_science)

[有许多好的开源和商业规则引擎。在创建自定义DSL之前，我会考虑这些因素。您编写的逻辑与这些系统非常匹配。

规则引擎和DSL的一些技术缺点是：

• 规则系统可能很难测试
• 您必须仔细设计规则的输入和输出
• 您需要了解，记录和集成其他工具或自定义DSL解析器
• 构建规则是与某些开发人员所惯用的思维模型不同，并且可能需要一些时间才能做好。