在一个业务系统中,有些规则逻辑就是与或非,有些规则是计算类。 什么样的规则适合进入ODM,那些业务逻辑不适合? 业务逻辑的粒度怎么划分比较好(划分太细规则太多,划分太大规则不能灵活变更)?可有什么最佳实践。
在我行,虽然没有明确的规范,但是观察现有使用规则引擎的系统,可以看出几条事实上的指导原则:
1)规则是否有必要分离部署?如果规则非常简单,通过一条IF-ELSE语句可以实现,而且这个系统中的规则处理相对分散,难以集中提取,则不需要使用规则引擎。
2)规则是否可以在数据读取时一并处理?如果某些规则可以通过SQL实现,那么一般我们都是让数据库通过SQL来实现;把大量的数据读取出来再交给规则引擎进行规则处理的方式相对臃肿,其效率也低。
除了上面两种情况之外,剩下的规则处理就可以使用规则引擎了。
主要应用于两种情况:
1)规则简单但是大量重复使用。比如流程管理系统;
2)规则复杂。主要是一些复杂数学、逻辑运算相关的处理,包括:利率计算、客户评分计算、预警信号计算,等等。
收起ODM有简单规则、规则表、规则树、规则流等实现方式,规则表通常用于积分计算或者一系列相似规则操作,简单来说就是可以把用Excel表现的业务逻辑转化成ODM中的规则表;规则树适合分段规则‘;简单规则也就是语言描述,在设计的时候不同的写法可能造成不同的性能表现;规则流可以用于串联多个规则,形成完整的业务逻辑。
因此粒度划分的通常做法是:先划分为多个规则包,规则包中有相应的实现规则,用规则流串联起所有的规则包(规则流的流转可以写规则逻辑)。这样做的好处在于:可以让引擎自动判断流转的顺序,大大提高性能;业务划分也比较清晰明了