规则引擎根本上其实是为了增加软件的可维护性。为软件提供可供用户直接修改业务逻辑的功能。也就是说用户的需求改了,最好不要软件公司参与,用户就可以直接修改。这样软件项目不会因为维护成本太高,而最后亏本。
一般我们考虑将可变的逻辑部分,单独分离出来,用规则引擎来加以实现,这样可以有效地解决用户逻辑的变更问题。 这些问题说说容易,其实真正要做到这点还是很难的。就比如说可以满足用户需求的不断变化,用户需求的变化有时不光只是体现在逻辑方面,有些时候还涉及到操作界面和数据结构。特别是作为软件公司不能分析出来那些可变的规则,仅仅提供一个规则引擎的实现不能很好的解决用户需求的变更问题。 因此我们希望有一种产品,不光可以解决业务处理逻辑的改变,而且需要解决数据以及界面的变动问题。 VisualRules从一开始设计时就考虑到这些问题,因此VisualRules不光是一个规则引擎的实现,而且还提供了数据以及界面的快速实现问题。
-*-----------------------------------------------------------------------------------------------------*----------------------------、
复杂的事情 总会是非常复杂的。
以Jboss的 drools来说吧。 它让你规则条理化,当然如果你很粗鲁的写一些规则,你没有很规划的去写规则,会发现你的drools文件会更加让人难以阅读。规则引擎其实也只是做了if else之类的东西,只不过它给大家更加直观的规则管理方式. 就说我们目前使用drools的背景吧: 网站上面大约有将近20种事件,每种事件都会有一堆的规则。而且规则都非常复杂,改动又比较大。客服可能会随时去修改一种规则的风险数值。那么传统的代码模式显然很难满足现状而且这些规则的逻辑也很难理清楚。 基于上面的现状后来开发了一套基于Jboss Drools规则引擎开发框架与风险处理系统。 针对每条规则设置一个风险值,如果一个事件匹配到一条规则其风险值进行累加,再根据最终的风险分数来决定对这种事件到底要采取什么措施. 凡是没有绝对。看哪些东西适合我们去用,采用一些最新的技术代价要多少、风险又有多少。 |
|