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