design-patterns - 在解决方案中实现业务规则引擎的方法或模式？

Question

我在一家年轻的银行公司工作。我们的解决方案 (.NET) 有一个重要的技术债务，因此我们按照 DDD 原则对其进行了重构。我们计划使用 (a) 业务规则引擎。业务规则涉及会计目的、营销目的、风险目的、法律问题……我们计划 POC 由企业赞助的 BRE。

我正在寻找成功采用 BRE 或 BRE 组合的人的反馈？

是否有管理 BR 存储库的工具？

是否有任何模式可能有助于分离流程和 BR ？

你知道一些作者写过关于将解决方案迁移到
布雷？

您认为采用独特的 BRE 是否可以满足所有领域的需求，
还是为每个域设计一个自定义解决方案的原型(prototype)更好？

什么是常见的陷阱？

谢谢，

Answer 1

所以，这有点夸张，但我还没有看到业务规则引擎在生产环境中运行良好。我唯一一次看到它们运行良好是当它们被完全视为它们正在替换的代码存储库时。

他们需要遵循 SDLC，经历需求收集、开发(与工程师一起)、QA，最后推广到生产。

规则引擎通常作为绕过开发、测试和源代码管理成本的方式出售给业务人员。这些系统通常会在很短的时间内分崩离析。规则是编程逻辑，它们是从某处的数据库加载而不是从文件系统加载的事实不会改变任何事情。作为编程逻辑，最适合开发它们的人是……程序员。

当业务人员尝试编写这些东西时，当系统无法阻止他们制造流程陷入的逻辑漏洞时，他们往往会很快感到沮丧。程序员习惯思考的事情。

这真的只是一个忠诚的问题。您正在用一种高保真编程语言(java、c、python)换取一种低保真语言。您并没有神奇地减少决策点的数量。您只是在尝试用一种必然受到更多限制的语言来表达它们。当你尝试用低保真语言表达更复杂的问题时，你最终会创造出一个怪物。数百或数千条规则以菊花链形式连接在一起。只有一两个人能够理解它，它很快就会成为组织的巨大责任。

也许你的公司不一样，但我已经看到这种情况发生了几次，通常唯一的出路就是报废和重建。我见过运行良好的业务工作流引擎。仅以相当高级的方式协调较低级别逻辑部分的事物。但是将所有真正的决策留给较低级别​​的机器。但是，这些也需要保持原位，并进行可行的推广、质量保证等。