业务规则分类

本文探讨了业务规则引擎和工作流引擎在项目中的适用场景。规则引擎适合处理数据结构确定且规则平级的业务,如电信计费规则,而工作流引擎则关注流程控制。当规则引擎支持数据库结构变更时,能承担大部分后台逻辑,减轻工作流引擎压力。业务规则可分为两类:数据库操作逻辑和技术人员维护,以及业务人员关注的表格规则,后者通常用Excel维护并集成到规则引擎。
摘要由CSDN通过智能技术生成

    最近几年,在很多的产品中越来越重视业务规则引擎的实现。比如IBM目前主推的一些产品线中,单独针对业务规则进行了强化。但是在实际的项目应用中,却发现究竟哪些应用,或者那些规则适合采用业务规则引擎来进行实现,而其他的一些规则适合采用工作流引擎或者报表引擎来进行实现。

    这个问题,其实和不同规则引擎的适用面有关。一般的规则引擎,最适合是那些数据结构确定的业务规则的处理。特别是这些规则是非常雷同的,可以说是平级的,然后反复的对同一批数据进行匹配处理。比如电信计费规则,是针对用户的使用数据,有很多同级的套餐规则,然后将这些数据,用所有的套餐规则算一遍。这些套餐规则,基本都是平级的,偶尔有些具有先后顺序的,也只是采用一些标记来进行控制。

    就这类业务规则引擎来说,规则引擎的应用还是非常单一的。如果规则非常少,或者说和数据结构的关系比较紧密,就不适合采用规则引擎来做。这类业务规则,可以在工作流引擎中,有些直接就采用sql语句等解决,或者说采用脚本语言来进行解决。因为规则引擎的应用反而显得非常累赘。

    业务规则引擎经过扩展功能后,需要加上对数据结构的变更支持,特别是支持数据库结构的变更。这样的话,业务规则引擎就不仅仅只是对数据处理逻辑的实现,而且是数据层的处理实现。

    这类业务规则引擎,就可以将绝大部分的项目中需要用到的后台逻辑采用业务规则引擎来进行实现。如此一来工作流引擎的压力就会大大减少,其只需要处理表单、流程控制等,其他的一概都可以交给规则引擎来进行实现。工作流就只需要处理流程相关的一些数据结构,即使一些业务数据,也只需要事先传给工作流实例就行了,而不需要再去考虑业务相关的其他一些数据结构等。

   在此类业务规则引擎的

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值