在一个系统中业务规则占据了相当大的比例，而且是变动最为频繁的，我们总是希望把容易变动的和不容易变动的分离开来，这样就不至于因为修改易变的部分影响不需变的部分，从而简化系统修改的复杂性，也提高系统的灵活性。
在一个系统中我们把组成部分拆分为数据，逻辑，界面等几个部分，其中数据又可以进一步拆分为水平和垂直部分，对于逻辑绝大部分是”如果-那么”这种形式，对于界面部分可拆分为页面，控件（文本框，下拉框，日期，文件，图片，单选框，多选框等）和展示权限（可看，可编辑）。
业务逻辑从本质上来讲就是一种规则的集合，数据和展示都是规则实施的对象，规则甚至也可以对规则起作用，这样就成了规则的规则。因此如果要设计规则引擎那么这个规则必须要可以引用和操作数据（水平，垂直），页面，控件，规则等组成部分。
上面也提到规则大部分是“如果-那么”这种形式，这种形式从本质上讲可以看做“条件-执行”，这样所有的规则都拆分为规则条件和规则执行体两部分。规则有作用域，顺序，黑名单，白名单，例外等。
对于规则的形式我想到了几个简单的例子：
- 当客户生日时产品折扣为0.8
rule "1":
if
[Customer].[Birthday]=[Today]
then
[Product].[Rate]=0.8
else
[Product].[Rate]=1
end
- 在2013-11-01到2013-11-10期间产品货号73022101折扣0.8
rule "2":
if
[Today]>=[2013-11-01] and [Today]<=[2013-11-10] and [Product].[sCode]=73022101
then
[Product].[Rate]=0.8
else
[Product].[Rate]=1
- 操作员级别为3的执行规则1，其他的执行规则2
rule "3":
If
[Operator].[level]=3
Then
[Rule “1”].Active=true
[Rule “2”].Active=false
Else
[Rule “1”].Active=false
[Rule “2”].Active=true
End
- 员工类型为采购时入库价可见，其他用户不可见
rule "4":
If
[Operator].[type]=”采购”
Then
[Product].[Price_in]. Visible=true
Else
[Product].[Price_in]. Visible=false
End
以上规则是在配置文件中的，可方便修改而不用修改程序和进行编译，也可以缓存起来以提高性能。
规则的表现形式可以是xml，脚本，逻辑语言，图像，如果能实现一个规则设计器可以大大方便规则的制定，降低规则学习的门槛。
因为要保证规则的全局性，那么对所有的数据查询，修改都要经过这个规则校验，因此数据操作需要一个集中的入口或者出口，所有对数据的操作都要有个用户id，规则引擎根据id和规则库来校验操作的合法性。
因为要保证界面权限和模型权限的一致性，因此要开发一套可以根据权限来自动展现的控件库。
引入规则引擎对开发模式影响也是很大的，由于业务规则从系统中分离出来，数据的基本操作都可以变成简单的增删改，有利于程序自动统一处理。开发的重点变成了开发规则执行的规则，简单的说就是制定规则的规则。系统初始化后只有一个设计器，通过设计器建立行业模型，再通过设计器对模型进行规则限制，这些工作将转移到实施部门进行，不需要开发部门进行干预。由于建立一套行业规则的工作量是很大的，因此可以预置几套行业规则模板，同一套系统在不同的规则下来适应不同的行业业务。
改造后的系统最终变成 “原型系统+规则=行业软件”，当然此想法很初步和不成熟，建立一套这样的系统难度和初期工作量也很大，但是一旦建立起来后系统灵活性大大提高，后期随业务变更变的容易，变更成本更低，更具市场竞争力。