1， 多变业务
开发系统时，有没有试过下面的情况，如果你试过，那可以考虑一下使用规则引擎了。
|
序号 |
问题 |
举例 |
|
1 |
业务规则来自于一个或多个表格 |
商店的会员积分表，停车场的计费标准，快递费的计算表，客户信用评分表 |
|
2 |
业务规则是客户自己写的，难以结构化。 |
工资计算办法，生产配方计算，保险计算，公式系统。 |
业务规则来自于表格，一般情况下表格有多个列，而这些列之间有条件和结果关系。如：
|
积分 |
会员等级 |
打折 |
|
0-100 |
普通会员 |
-- |
|
100-1000 |
白银会员 |
0.99 |
|
1000-5000 |
黄金会员 |
0.9 |
|
5000~ |
VIP |
0.85 |
这三列中，积分和会员等级就是条件，而打折往往就是结果，通常都是通过条件找到结果，上述表格可以用数据表保存起来，但这个做法真不提倡，上表也许是用户随手搞的，可能过一两个月就会变。
这些基于表格的规则，可以理解为结构化的规则。
但用户常常都会有非结构化的规则要求软件公司实现的，如上表，客户增加如下要求：A，入黑名单的会员不打折，B，3月8日妇女节，女会员折上折98，C，商品X不参与打折。
那就不是表格式的规则了，可以理解为非结构化的规则。
事实上，非结构化的规则，简直就是用户随手编写的公式，也许很多会员系统已经处理了这些问题，但对于小开发团队或行业经验还不够丰富的团队来说，上面的要求就是“变态”，因为自己实现不了。
2，规则引擎
规则引擎就是为了处理复杂多变的业务而出现的，而把这些变化封装到规则引擎中，提供通用的接口，让实施人员或客户在不改变低层代码的前提下，可以比较简单地改变规则。
CKRule规则引擎并不是使用rete算法实现的，而是使用编译，即规则都是代码来实现，基于.Net4.0的C#语言编写的。
上面的问题，规则引擎都处理得非常好。对于表格式的数据，可定义决策表进行处理，对于非结构化的规则，就直接编写公式来处理。对表格式数据，需要先标出条件列和结论列，引擎扫描每一行数据，用条件列来判断条件是否正确，如果成立就执行结论列的数据。
而针对非结构化的规则，开发员可以在引擎中定义非常简化的关键字，对比逻辑和结论操作。并在业务系统调用这些定义，开发出适合当前业务系统的界面，提供友好，简单的公式编辑。在CKRule中，非结构化规则被称为客户规则池，其架构图如下：
从上图中，可以清楚看到，终端用户始终在业务系统上面操作非结构化的公式编辑，和测试编写的公式，保存之后被放在数据库中，终端用户是不需要与引擎直接接触的，这一特点就是强大的客户规则池功能。
即使你遇到再无厘头的业务规则要求，都可以在引擎中编辑好基础的元数据，然后在你的业务系统中编辑公式。这些公式是使用C#编译的，你可以非常简单地改变任何业务规则。如果开发员定义的关键字，比较逻辑和结论逻辑足够完善或客户公式足够简单，那把客户规则完全交给客户来编写，是绝对可行而且非常节约成本的事。
想了解CKRule的体系结构，案例和下载应用，请查看：