我在一家年轻的银行公司工作。我们的解决方案（.NET）有一个重要的技术债务，因此我们按照 DDD 原则对其进行重构。我们计划使用业务规则引擎。业务规则涉及会计目的、营销目的、风险目的、法律内容……我们计划对由企业赞助的 BRE 进行 POC。
我正在寻找成功采用 BRE 或 BRE 组合的人们的反馈？
- 有管理 BR 存储库的工具吗？
- 是否有任何模式可能有助于分离进程和 BR ？
- 您是否认识一些撰写有关将解决方案迁移到
布雷？
- 您认为采用独特的 BRE 可以满足所有领域的需求吗？
或者为每个领域设计一个自定义解决方案原型是否更好？
- 常见的陷阱有哪些？
Thanks,
所以，这有点咆哮，但我还没有看到业务规则引擎在生产环境中运行得很好。我唯一一次看到它们工作良好是当它们被完全像它们要替换的代码存储库一样对待时。
他们需要遵循 SDLC，经历需求收集、开发（与工程师一起）、质量保证，最后升级到生产。
规则引擎通常作为绕过开发、测试和源代码管理成本的方法出售给业务人员。这些系统通常会在很短的时间内崩溃。规则是编程逻辑，事实上它们是从某个数据库加载而不是从文件系统加载，这不会改变任何事情。作为编程逻辑，最适合开发它们的人是……程序员。
当业务人员尝试编写这些内容时，当系统无法阻止他们制造流程陷入的逻辑漏洞时，他们往往很快就会感到沮丧。程序员习惯思考的事情。
这实际上只是一个忠诚度问题。您正在用一种高保真编程语言（java、c、python）来交换一种低保真语言。你并没有神奇地减少决策点的数量。你只是试图用一种必然更受限制的语言来表达它们。当您尝试用低保真语言表达更复杂的问题时，您最终会创造出一个怪物。数百或数千条规则以菊花链方式连接在一起。由于只有一两个人能够理解它，它很快就会成为组织的巨大负担。
也许你的公司是不同的，但我见过这种情况发生过几次，通常唯一的出路就是报废和重建。我见过工作得相当好的业务工作流程引擎。只是以相当高级的方式协调较低级别逻辑部分的事物。但将所有真正的决策留给较低级别的机构。不过，这些也需要保留在原来的位置，并有可行的促销、质量保证等。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
