关于drools 的一些想法

1.规则里面很多的判据不是直接就具备的，需要一些整理过程，那么这些整理过程到底是在Java类里面做还是在Drools规则里面做？举例子说：
规则如下：
如果用户购买的商品中有两个以上的A产品和一个B产品就打85折。
如果用户购买的商品中有两个以上的B产品，就打8折。

在实际开发中，我们会把用户准备购买的产品都放在一个列表中。
如果要应用规则引擎，直接以产品列表为“事实”是最理想的，但是以直接以产品列表为“事实”就需要在规则中插入Java代码，用来整理出产品A和产品B的数量。这样一来，整理产品列表的Java代码就脱离了Java的运行环境，调试起来比较困难。至于更复杂的一些业务规则，用Rule去实现岂不是很难阅读和理解？

如果我们不直接以产品列表为"事实"，而已采购的产品A和B的数量为事实，那么在调用规则之前，就要在Java中整理产品列表，求出产品A和B的数量，然后将其作为“事实”调用规则。此种方案的缺点就是不够灵活。一旦规则变化了，需要纳入产品C的数量来作为打折的依据，那么既要修改Java中整理产品列表的代码，又要修改规则文件。这也是我们不愿意看到的场面！

2.所谓的“业务规则”和“业务逻辑”区别到底在哪？是不是所有业务逻辑都可以看做是“业务规则”？如果是这样，那么复杂的业务逻辑或者说复杂的业务规则用规则文件去编写是否合适？如何把握将哪些业务规则用规则引擎去实现的度？


3. 如果要推入工作内存的事实量较大，或者需要用到的规则量较大，规则引擎的性能可否满足要求呢？

4. “部门经理（角色）能够批准2天以内的请假，总经理（角色）可以批准2天以上的请假”，这样的规则算不算业务规则？这样的规则中，什么是事实，什么是结论？在工作流的场景下，我期望的是给出申请的请假天数，然后根据业务规则找出可以批准的角色，然后将工作任务发给该角色。那么规则引擎是否具有这样类似的查询功能呢？或者我该如何去实现？






建议:规则是可以动态加载的，在线上环境下更新，不需要停应用的，建议尽量放在规则里面，还有现在都有eclipse插件支持调试的，对于简单的计算应该还是方便的。如果是很复杂的业务逻辑，或者要组装一个很复杂的对象，肯定要放在java处理比较好。