前篇随笔《需求收集、分析》中简单提了一下业务规则。业务规则是很重要的一个东西，并且用户对于业务规则也极易
更改或者新增新的业务规则.尤其是在某些场合如促销，积分商城等场景。正因为规则如此重要，建议使用单独的文档
维护，规则名称编号可以与用例名称编对一一对应。
业务规则分类：
一,内禀规则：业务实体本身的规则。如订单中销售记录不能为空，数量不能为等。
二，全局规则：一般与所有用例相关而不是某个特定用例相关。例如系统安全方面的sql注入，ddos攻击等。
三，交互规则：用于用例当中。
它们规定了满足什么条件后业务将如何反应。有些规则需要开发成系统用例。比如人事
管理系统中请假业务只有工作日才计入请假天数，那么这个工作日就需要电脑来维护了，会作为一个系统用例存在，并
且作为请假用例的前置条件。 交互规则又是最容易引起.
交互规则如此灵活多变，需要良好的设计才能保证系统的扩展性和可维护性。如何做：
思路一：
在 javax.swing.border包提供了Border接口和几个不同的Boder的实现。在swing中每个组件提供了paint方法，每
个组件知道怎么画自己展示自己的外观。那么我们可以提供业务规则处理接口，每个具体业务规则自己知道怎么处理业务。
可以用简单工厂来决定调用哪一个具体业务规则。这个是策略模式的使用,缺点是新增具体业务时工厂类会修改。也可以
用观察者模式来实现，所有的具体业务类都来观察这个业务规则，自己判断是不是自己可以处理的，不是就不理会。
基于策略模式的规则实现类图:
思路二：
规则引擎比如drools处理一些问题 。规则引擎适合于做业务规则频繁变化的场景.把业务规则抽出来通过规则引擎来
处理。类似工作流系统的概念。
自定义规则处理库:
一些动态的语言很适合来做这样的事情。java支持script.Mvel是一个表达式语言，drools也支持mvel来处理业务规则.
这里自定义规则引擎使用Mvel表达式语言.
规则文件示例：
<rules>
<!--rule-set 是一个规则集,执行规则 rule1时会迭代规则集里面所有的规则(mvel-rule)-->
<rule-set name="rule1">
<!-- id是规则的标识，也是默认的排序处理顺序。exclusive 是排它。如果为true,则当前规则执行后，不再执行后面的规则-->
<mvel-rule id="step1" exclusive="false">
<block><![CDATA[
if(salary<=3500) {result=0;}
]]></block>
</mvel-rule>
<mvel-rule id="step2" exclusive="false">
<block><![CDATA[if(salary>3500) {result=1};]]></block>
</mvel-rule>
</rule-set>
<rule-set name="rule2">
<mvel-rule id="step1" exclusive="false">
<block><![CDATA[
import com.custom.rule.*;
rs = new RuleSet();
rs.name="asdf";
rs.print();
]]></block>
</mvel-rule>
</rule-set>
</rules>
rule2中可见mvel可以导入未知jar包并进行处理，确实强大，就有了足够的灵活性.
自定义规则库源码及使用示例下载.
本例依赖xstream1.4.9 ,mvel2.0
自定义规则库除了可以应用于一般系统业务处理，当然也还可以用于大数据处理。比如hadoop/spark统计用户积分等
如果再定义一套配置规则的UI。。。好的，业务人员可以自己设置计算规则了。