业务规则分类

    最近几年，在很多的产品中越来越重视业务规则引擎的实现。比如IBM目前主推的一些产品线中，单独针对业务规则进行了强化。但是在实际的项目应用中，却发现究竟哪些应用，或者那些规则适合采用业务规则引擎来进行实现，而其他的一些规则适合采用工作流引擎或者报表引擎来进行实现。

    这个问题，其实和不同规则引擎的适用面有关。一般的规则引擎，最适合是那些数据结构确定的业务规则的处理。特别是这些规则是非常雷同的，可以说是平级的，然后反复的对同一批数据进行匹配处理。比如电信计费规则，是针对用户的使用数据，有很多同级的套餐规则，然后将这些数据，用所有的套餐规则算一遍。这些套餐规则，基本都是平级的，偶尔有些具有先后顺序的，也只是采用一些标记来进行控制。

    就这类业务规则引擎来说，规则引擎的应用还是非常单一的。如果规则非常少，或者说和数据结构的关系比较紧密，就不适合采用规则引擎来做。这类业务规则，可以在工作流引擎中，有些直接就采用sql语句等解决，或者说采用脚本语言来进行解决。因为规则引擎的应用反而显得非常累赘。

    业务规则引擎经过扩展功能后，需要加上对数据结构的变更支持，特别是支持数据库结构的变更。这样的话，业务规则引擎就不仅仅只是对数据处理逻辑的实现，而且是数据层的处理实现。

    这类业务规则引擎，就可以将绝大部分的项目中需要用到的后台逻辑采用业务规则引擎来进行实现。如此一来工作流引擎的压力就会大大减少，其只需要处理表单、流程控制等，其他的一概都可以交给规则引擎来进行实现。工作流就只需要处理流程相关的一些数据结构，即使一些业务数据，也只需要事先传给工作流实例就行了，而不需要再去考虑业务相关的其他一些数据结构等。

   在此类业务规则引擎的基础上，就可以对业务规则进行一个分类。不同的分类采用不同的管理方式。

   某一类业务规则，是纯粹和数据库结构相关的。比如增、删、改、查的逻辑等。这类业务规则侧重于数据的类型转化，或者一些简单的处理，大量的都是数据库操作的SQL语句等。这类业务规则一般都由技术人员来进行维护，因此在采用规则引擎进行实现时，这类规则就没有必要放到业务规则管理系统中，进行一些权限控制、版本控制等。而是有技术人员通过自身的配置管理技术来进行维护。在处理这类业务规则时，特别需要注意的是减少数据操作的次数。因此数据尽可能在规则中处理完，然后再交给数据库去处理。

    另一类业务规则，是业务人员比较关心的，特别是一些表格类的规则，比如像一些决策表，或者一些参数表，基础数据表。这些表业务人员一般情况下，喜欢采用Excel来进行维护。对于这类规则，就需要将这类表格还是采用Excel来进行维护，同时在规则引擎的实现中，将Excel表格数据进行集成。这类规则需要采用业务规则管理系统进行管理，供业务人员查阅和修改。

    在后台的业务规则处理中，基本上分为这两类业务规则。因此在具体的实现中，要注意加以区分。