我在项目中一直使用JBoss Drools 这个开源的规则驱动引擎， 为什么要用它？ 我要想出个一二三来说服别人。
对于business rule, 一般的情况是， 好的BA，可能更善于发现、抽取business rule ，并用结构化的方式描述、记录下来， 普通的BA可能更是一种流水账式的、吃那拉那的描述方式。
不管怎样，BA在写文档，use case的时候，那些business rule被分布在文档中不同的部分，然后这些rule，在分工时，有被理所当然的分给不同的开发人员来开发。
好的开发人员会刻意的使用各种手段剥分离、封装、结构化他们，并积极的重构他们，以防止规则的变化，冲击到设计或代码的结构。
而普通的开发人员则极有可能硬编码写死在代码当中，完成coding 任务，草草了事。
可以看出，这种方式，随意性太大，不可控的风险也随之增大。后果是，开发人员总是抱怨需求的变更，殊不知，合理的设计手段，在一定程度上，可以缓冲需求的变化。
JBoss Drools, 它在一定程度上解决了上面的问题：
1）规则首先应当是可管理的
规则是相对灵活、复杂的，我们要控制、管理它们，而不是直接暴露给开发人员，愿意怎么搞，就怎么搞，一个人一种style。
Drools使用script，将rule集中写在规则库文件当中， 使得设计人员更容易管理。同时可以设计复杂的业务规则，并在没有编写任何代码的情况下自动绑定企业数据。提供带有菜单提示和下拉列表的向导来帮助用户完成设计过程。
2）我们则设计是，总要遵循一些原则：
将易变的和不变的分离出来
封装可变的规则， 避免硬编码编程
将多源的规则，合并、整理成单源的规则，一进一出，降低复杂度。
Drools将规则写在配置文件当中，以集中强制的方式剥离了规则，而不是写死在代码当中。在规则变化而修改脚本文件时，不用重新部署系统。
3）规则应当使用一种清晰、易懂的方式记录下来，并明确下来，无论是汉语还是英文句子，都不是表达规则的好的方式。大段大段的文字，往往让人发晕。
伪代码、script语言反而时表达规则的一种极好的方式， 结构化的表达方式，让开发人员觉得非常亲切，更加平易近人。
Drools 引入了更为强大且的业务行为脚本语言（MVFlex表达式语言）。用户会发现脚本语言的引入使得代码变得更为简明且可读性更好。