一个包含规则引擎的系统是否真的成功了？

我们的系统(外来商品衍生品贸易捕获和风险管理)很快就会重新开发.我听到的一个建议是,将整合一个规则引擎,使最终用户(商品交易者,如此相当复杂)更容易对业务逻辑进行某些更改.

我对规则引擎有点怀疑.我的敏捷主义者想知道它们是否只是一个过程问题的技术解决方案......即.我们的开发人员需要很长时间来响应业务变更的需求.该问题的解决方案应该是更加协作的开发方法,更好的测试覆盖率,更全面的敏捷实践.

听取规则引擎真正有利的情况(特别是在交易环境中)肯定会有所帮助.

我见过两个使用Fair Issac的Blaze Rete引擎的应用程序.

一个应用程序将数千条规则抨击成一个单一的知识库,有可怕的内存问题,已成为一个很少理解的黑匣子.我不会称之为成功,但它正在生产中运行.

另一个应用程序使用决策树来表示医疗表单上数百个问题的顺序来处理客户.它做得非常优雅,业务人员可以根据需要更新规则,而无需涉及开发人员.(但仍然必须由一个人部署.)我称之为非常成功.

所以它取决于问题的重点,规则集的大小,开发人员的知识.我的偏见是,简单地将规则引擎作为单点故障并将规则倾倒到其中可能不是一个好方法.我将从数据驱动或表驱动方法开始,并在需要规则引擎之前进行扩展.我还会努力将规则引擎封装为对象行为的一部分.我会从用户隐藏规则引擎,并尝试将规则空间划分为域模型.

我不知道我是否说他们真的是一个福音,但我认为他们肯定是有价值的.我在保险行业工作了几年,其中规则引擎非常成功地使用,允许业务用户创建规则,确定哪些策略是合法的,具体取决于州.

例如,如果您必须在某些州拥有自付额,或者不允许某些免赔额和自付费组合,可能是出于产品考虑,或者因为州法而完全违法.

公司运营的州数量,以及规则的不断变化(季度)将使这成为令人眼花缭乱的编码实践.更重要的是,它不是程序员的专业知识.它增加了额外的无意义通信,最终用户正在描述要对不像保险业专家的程序员实施的规则.

设计正确,规则引擎仍然可以启用允许良好测试的工作流系统.在这种情况下,规则存储在数据库中,并且有QA和PROD数据库.因此BA可以在质量保证中测试他们的规则,然后将它们推广到PROD.

与任何事情一样,它通常与实现有关,而不是实际技术.

是的,Microsoft在BizTalk中有一个业务规则引擎(BRE)已成功使用多年.我听说他们有客户为BRE购买BizTalk(非常昂贵).

根据我的经验,让业务用户更新规则的实用性很小.通常需要技术人员来处理业务规则编辑器.