规则引擎是面向技术人员的工具。目前技术人员为什么会选择规则引擎来使用，主要是基于如下情形来考虑：
1、业务逻辑从程序代码中脱离出来。通过配置来实现业务规则。
2、业务规则的变更，可以直接由用户通过web界面来修改和变更。
针对这一类需求情况，其实我们有一般由以下的几种可选方案：
1、选择规则引擎来实现。
现有的规则引擎产品一般都能满足以上这两种要求。可以不用代码，比如Java来实现业务逻辑，而采用规则语言通过规则配置器来完成。用户需要变更时，一般都会提供C/S或者B/S版本的规则配置器来实现。
2、采用动态语言：
直接采用JS或者其他的动态语言BeanShell等，也可以实现不通过Java代码来实现业务逻辑。通过也可以提供一个编辑界面，让用户来进行修改。
3、表格配置或者自定义公式
通过定义一个表格或者加上一定的自定义公式语法来实现具体的逻辑。
以上几种方案，在不同的项目中，都有各自的优缺点：
1、采用规则引擎实现，使得业务规则的配置更加标准化、专业化。同时一般的规则引擎都会对修改的记录进行版本控制，以便于跟踪、测试、恢复等操作。规则配置器一般提供的界面，更加人性化，用户使用上更加便捷。缺点是会使得整个系统的架构变得庞大，需要有人专门负责研究规则引擎，以及相关的配置和管理工具。
2、采用动态语言的实现，对于开发上会更加简单。动态语言一般纯粹处理逻辑，因此接口设计上会更加容易。同时使用动态语言时，一般很少会去考虑继承关系、相互调用等问题。缺点是可支持的逻辑相对扁平化，也相对简单。同时动态语言需要有个学习过程。
3、通过表格配置以及自定义公式，是一般项目中最常用的。通过一个配置表来实现对应管理、逻辑流转。这种方式对于用户来说最友好，用户操作上更加方便，问题也最少。缺点是不够灵活，开发工作量大。
以上这些考虑，都只是从一个技术角度出发，如何将一个技术编码工作，因为需求的不断变化，而更换一种实现方式。使得不会因为需求变化，而造成对代码的改动。因为代码改动会带来一系列的问题，变更流程、测试、部署等等。
但是我们既然已经将和业务相关的业务逻辑，从程序中脱离出来，就不能仅仅停留在开发实现阶段。而应该将其纳入到客户的管理系统中。成为用户系统管理的一部分。比如我们至少应该考虑，用户可以查阅有多少业务规则，是可以由用户配置，哪些人对哪些业务规则有查看、创建、修改、删除权限，谁在何时进行了修改，谁负责的测试，测试结果如何，什么时候应用了新的修改之后的业务规则等等。
在这种情况下，我们不能仅从规则引擎工具的角度来考虑这个实现问题，而应该从规则库管理角度来考虑问题。
因此，不管我们是采用规则引擎还是动态语言，来实现业务逻辑供用户自己维护修改。就应该加强更多的用户维护方面的管理功能，使得这个工作更加标准化、规范化。
实现一个业务规则库，需要考虑以下方面的问题：
1、用户权限管理。采用现有的应用系统的权限系统，增加相应的针对规则的权限设置。
2、规则权限设置时，需要考虑查看、创建、修改、删除、测试、审核、发布、执行等权限。
3、规则分类的考虑。考虑多种方式来进行分组，用户角色权限按照规则组进行分配。
4、规则版本控制：可以设置规则的版本号，可以设置规则组的标签，以便测试发布是区分。
5、规则的单独测试：对于规则的测试，可以设置批量测试用例，可以在线执行测试。
当然，如果应用系统是集群的，还需要考虑集群方面的问题。因此规则的执行中，最好是无状态的。
在将业务规则从程序中脱离出来进行管理，是解决用户需求变更的有效手段，同时我们应该需要用规则库管理的思想来更近一步，达到规范、标准、统一。