business-rules - 实施企业级规则引擎时的前五个挑战是什么？

Question

我已根据我的知识编制了列表，但希望使用此社区输入来丰富和优先考虑它。我知道拥有一个集中的规则存储库本身是有争议的，但我们可以有单独的问题。

1. 业务用户使用平台编写规则的适应性[定义、分类、决定可能在规则存储库中运行的规则]
2. 易于从不同应用程序调用和使用规则
3. 规则可移植性- [RIF（规则交换格式）重要性？]
4. 规则维护– BRMS [业务规则管理系统]
5. 规则引擎性能- [多少、多快和多可靠]

Answer 1

以下是我基于 12 年使用 3 个规则引擎的经验得出的结论（按重要性排序）：

1. 在系统安装和测试后，无需任何 IT 参与即可创建、编辑和部署规则。只要引擎带有正常的 API，我可以拥有版本、批准、测试和调试我的规则的能力，但并不重要，因此我可以按照我需要的方式自己构建该功能。我不确定“平台”，只要给我一个体面的 UI 用于规则创作和编辑，最好是基于 Web 的 UI。
2. 规则执行性能应该是优秀的。怎么强调都不为过：缓慢的引擎几乎总是会导致利润损失。在我的生活中，引擎必须能够在每个 2 毫秒内评估 50-80 个条件规则集（没有外部调用）（平均大约 1.5 毫秒是好的，0.5 毫秒是好的）。它必须是线程安全的，所有规则评估必须完全独立于彼此和引擎本身（规则缓存除外）。
3. 规则应以 XML 格式呈现，以便可以保存在任何地方。我不在乎它是什么样的格式，只要它可以工作并且在引擎版本之间保持一致。我怀疑是否存在对不同组织之间“共享”规则的巨大需求。我绝对不希望与任何人分享我的规则 :) 规则存储库可能完全是邪恶的，因为我可能需要将我的规则从一个存储移动到另一个存储（例如，在合并的情况下，或者被其他人征用整个系统与其他类型的存储）。只要发动机的品牌保持不变，应该没问题。规则只是逻辑集合。目前它们存储在哪里应该是完全无关的。如果引擎不能从任何地方以预期格式加载规则，那么我不需要这样的引擎。
4. 能够创建、命名和保存小规则，然后通过它们的名称将它们组合到规则集中将是一个巨大的优势。

目前我能想到的规则引擎的所有其他特性都与我和我所做的事情无关。希望这可以帮助。