业务规则管理

业务规则管理（Business Rules Management，简称BRM）

在一个企业实体中同样存在着各种各样的规则，像管理制度、业务手册、工艺流程、操作规范、收费标准、促销策略等都是规则，甚至一些没有形成文字的惯例，也是企业规则的一部分。因为是与业务相关，所以又称它们为业务规则。

 

业务规则分散在企业的各个角落，就算企业的决策者也很难说清楚自己的企业内部到底有多少业务规则在使用。
大部分的业务规则存在于业务人员的大脑中，或是为数不多的工作手册、操作规范等非结构化的文档上。作为描述企业最重要特征的业务逻辑没有被有效地管理和使用，导致好的经验无法积累，差的经验无法总结。即使企业使用了计算机系统，业务处理逻辑也总是被看成一个个过程写进了程序代码中，当某些需求和业务规则发生变化时，必须修改原有代码，修改和维护的成本都相当高。

 

业务规则管理（Business Rules Management，简称BRM）技术的出现彻底改变了以过程形式处理业务逻辑的方式，它将业务规则的实现从具体的程序代码中抽取出来，以结构化的业务规则数据来表示企业的业务行为，使得业务规则与企业的数据信息一样成为企业的重要资产。与此同时，软件开发的习惯也开始因BRM 而改变。业务规则像数据一样独立于程序之外，业务人员可以使用行业术语而不是专业编程语言来编写规则，从而使企业的业务系统真正面向业务人员。

 

数据库把程序与程序所处理的数据进行了分离，它的出现使得数据不依赖于程序而独立存在，软件系统的升级无需对数据库系统进行改动，并产生了关系数据模型、数据库操作语言、数据库查询语言等新概念，以及数据库系统分析员、数据库开发人员、数据库系统管理员等新角色。

 

与数据库的出现相对应，把业务逻辑从程序代码中分离出来也将对软件的开发方式、软件的体系结构甚至软件开 发的组织结构都产生深远的影响。

 

业务规则管理将业务逻辑当做结构化的对象进行处理，使复杂的业务逻辑变成一条条简单的业务规则，而将业务规则之间的复杂逻辑关系交给规则引擎去处理，因此产生了业务规则引擎、业务规则库、业务规则开发方法学、业务规则管理系统等新概念，以及业务规则系统分析员、业务规则开发人员业务规则系统管理员等新角色。

 

业务规则管理系统的引入，使应用系统结构及其维护方式发生了巨大的改变：基于业务规则方法将大大缩短系统的开发时间；更加适应系统业务逻辑的变化；开发者可以直接使用业务规则的技术而无需了解过多的实现细节；大大减少了编程的工作量，减少了编程错误，使开发者更加关注系统本身的业务需求；基于业务规则的开发方法还模糊了系统需求分析、设计和编程的界限;业务规则库介于用户界面和数据库之间，系统具有更好的灵活性；基于业务规则的系统开发比定制开发更能节省费用，同时能满足用户的个性化需求。

 

不少软件开发商已经开始利用业务规则管理技术来开发商用软件，它们不仅能够为用户搭建规则库，让用户随意添加自己的业务规则，而且会在一些针对行业的应用中，将自己的行业经验以业务规则的形式加进去，为用户提供最佳实践经验。

 

分层和复用是当今软件开发的两大技术方向。分层技术解决了系统的复杂性问题，降低了系统内的耦合性;复用技术解决了开发的效率和可靠性。业务规则管理技术恰恰与这两大技术的特点相吻合，综合体现了分层和复用所带来的好处，并且很好地融合了数据库技术和面向对象技术的优势。

 

业务规则最基本的组成成份是用于表示它的语言，业务术语是人们用于定义事物的工具，例如术语表。一个组织的本质和运行结构可以用相关的术语来描述，如“客户下一个订单”。类似“数据不可以更新”这样的规则则能够限定和控制企业的某些行为。此外，利用业务规则可以从一种知识推导出另一种知识。

业务规则的属性包括名称、状态（被提议的、有效的、被核准的、存档的）、有效日期和终止日期、业务规则描述、表达式、触发事件等。其主要形式有决策表、决策树、规则语言和脚本。
● 决策表: 以表格的形式表示业务规则，每一行表示一条规则，列表示条件或动作，当所有条件满足时，执行动作。
● 决策树：将一组业务规则以树型结构来表示，每一个分支表示一条决策路径，叶子节点表示结果或动作。
● 规则语言：使用类似自然语言的句法描述规则。目前有很多种规则语言，每种语言适合解决其特定领域的问题，可以提供较好的性能，但比图形化的表示难于维护。
● 脚本（模板）：用于描述过程性的业务逻辑，是决策表、决策树、规则语言的基础。如：
IF...THEN ...ELSE...。
业务规则的应用特性如下：
● 业务规则的非“固化性”
固化在程序代码中的策略和规则必然是僵硬的。客户的多态性和市场的多变性决定了业务规则和策略的变化必然
很频繁，如果规则的每次改变都要求对系统程序进行“伤筋动骨”式的修改，那么系统的维护和升级必然代价昂贵，
甚至难以维持。
● 业务规则的“逻辑性”
业务规则具有逻辑性，每条约束行为的业务规则至少包含两个部分：条件部分和执行部分；规则的条件涉及到对
业务数据作用的判定，规则的执行涉及到对业务数据的处理。所以规则不是简单的业务数据。
● 业务规则的“非过程性”
每条规则只能定义对一种现象的判断和操作，复杂的业务逻辑应该由多条规则协同处理。规则的“非过程性”带
来的好处是：每条规则的制定变得非常单纯，可以“就事论事”，将复杂的过程处理平摊成一个个有条件的执行单
元，实现了从简单到复杂的知识积累过程。
● 业务规则的“事件触发性”
业务规则会根据相应的条件被触发执行，触发规则执行的“事件”就是业务数据本身。比如一套信用分析的规则
集合，一旦客户信用记录信息进入系统处理，这组规则将会被激活，并启动相应的分析过程。
● 业务规则的“非技术性”
业务规则是属于业务人员的，业务人员应该使用行业语言而不是专业技术语言（如程序语言、数据库语言、脚本
语言等）编写规则。