drools介绍

在很多行业应用中比如银行、保险领域，业务规则往往非常复杂，并且规则处于不断更新变化中，而现有很多系统做法基本上都是将业务规则绑定在程序代码中。

主要存在的问题有以下几个方面：

1） 当业务规则变更时，对应的代码也得跟着更改，每次即使是小的变更都需要经历开发、测试验证上线等过程，变更成本比较大。

2） 长时间系统变得越来越难以维护。

3） 开发团队一般是由一个熟悉业务的BA（业务分析人员）和若干个熟悉技术的开发人员组成，开发人员对业务规则的把握能力远不及BA，但实际上却承担了将业务规则准确无误实现的重任。

4） 系统僵化，新需求插入困难。

5） 新需求上线周期较长。

解决方案

能否让我们的业务系统更灵活一点呢？

思路：将业务规则从技术实现中提取出来，实现技术和业务分离，开发人员处理 技术、业务分析人员定义业务规则，各自做自己所擅长的事情。

方案：目前已经有比较成熟的开源产品支持，这就是本文所要介绍的Drools，我们将业务规则定义在Database或者BRMS(Business Rule Management System)中，通过管理DB或者BRMS实现业务逻辑的动态改变。

适用情景

什么时候应该使用规则引擎？

虽然规则引擎能解决我们的许多问题，但我们还需要认真考虑一下规则引擎对我

们的项目本身是否是合适的。需要关注的点有：

我的应用程序有多复杂?

对于那些只是把数据从数据库中传入传出，并不做更多事情的应用程序，最好不要使用规则引擎。但是，当在Java中有一定量的商业逻辑处理的话，可以考虑Drools的使用。这是因为很多应用随着时间的推移越来越复杂，而Drools可以让你更轻松应对这一切。

我的应用的生命周期有多久？

如果我们应用的生命周期很短，也没有必要使用Drools，使用规则引擎将会在中长期得到好处。

我的应用需要改变吗？

这个答案一般情况下是肯定的，“这世界唯一不变的只有变化”，我们需求也是这样的，无论是在开发过程中或是在开发完成以后，Drools能从频繁变化的需求中获得好处。


drools语法说明

http://kingsun1980.iteye.com/blog/459272/

drools  Accumulate函数介绍

http://hxpwork.iteye.com/blog/102540