Rén*_*ald 3 architecture enterprise design-patterns rule-engine business-rules
我在一家年轻的银行公司工作.我们的解决方案(.NET)有一个重要的技术债务,所以我们按照DDD原则重构它.我们计划使用(a)业务规则引擎.业务规则涉及会计目的,营销目的,风险目的,法律事务......我们计划将BRE由业务赞助.
我正在寻找成功采用BRE或BRE组合的人的一些反馈意见？
谢谢,
小智 9
所以,这有点咆哮,但我还没有看到业务规则引擎在生产环境中工作得很好.我看到它们运行良好的唯一一次是它们的处理方式与它们正在替换的代码存储库完全相同.
他们需要遵循SDLC,通过需求收集,开发(与工程师),QA,最后升级到生产.
规则引擎通常作为绕过开发,测试和源代码管理成本的方式出售给业务人员.这些系统通常在很短的时间内分崩离析.规则是编程逻辑,它们从某个地方的数据库加载而不是从文件系统加载的事实不会改变任何东西.作为编程逻辑,最适合开发它们的人是程序员.
当商务人士尝试编写这些东西时,当系统不能阻止他们制造流程所属的逻辑漏洞时,他们往往会很快受挫.程序员习惯于思考的事情.
这真的只是忠诚的问题.您正在使用高保真编程语言(java,c,python)进行交易,以获得低保真语言.你并没有神奇地减少决策点的数量.你只是想用一种必然更受约束的语言来表达它们.当您尝试用低保真语言表达更复杂的问题时,您最终会创建一个怪物.将数百或数千条规则菊花链式连接在一起.只有一两个人能够理解它,很快就会成为组织的巨大责任.
也许你的公司不同,但我已经看过几次这种情况,通常唯一的出路就是废弃和重建.我见过业务工作流引擎运行得相当好.只是以相当高级的方式协调低级逻辑的事情.但是将所有真正的决策留给了较低级别的机器.这些也需要保留在他们的位置,并有可行的促销,qa等.