业务规则⼊门简介运动员跳远>心理老师大本营
引⾔
业务规则，通常被⼈们描述为业务逻辑的外部化或业务⾃动化，是⼀种实现和强制实施业务策略的⽅法；⽽业务规则管理系统（BRMS ）则是加速变更过程的⽅法。在我作为业务规则架构师的经验中，帮助确定业务规则⼀直是最具挑战性的任务之⼀，因为业务规则⼀向难于理解。但是，如果理解了业务规则是如何构成的，则理解业务规则也不是那么困难。本⽂通过研究⼀个来⾃保险⾏业的实际⽰例，尝试揭开能将结构化逻辑分类成为业务规则的秘密。业务规则管理是总体业务流程管理（business process management，BPM）框架的⼀个组成部分。IBM® WebSphere®Process Server 的设计⽬标就是成为⼀个完全的 BPM 解决⽅案，并且业务规则也是其中的⼀个主要部分。本⽂还将提供了对 WebSphere Process Server 中业务规则组件的简要介绍。
业务条件⽰例
那么业务规则是什么呢？⽤最简单的话来说，业务规则是与特定⾏业中的特定业务功能有关的决策逻辑的表⽰形式。就业务和法律规章⽽⾔，保险⾏业是⼀个受到⾼度管制的⾏业，不遵守这些规章会付出相当惨重的代价。这些限制为该⾏业带来了必须采⽤更好的⽅法来管理其决策逻辑的需要，同时还使保险⾏业成为业务规则技术的早期采⽤者之⼀。为了介绍业务规则及其相对于过程代码的⼀些优点，本⽂将
查看⼏个来⾃保险⾏业的业务条件⽰例，并讨论为什么可以更好地将这些业务条件定义为业务规则管理系统中的业务规则。
⽰例 1：淘汰条件
在保险⾏业中，保险单处理时间是最重要的，系统应⽤程序的更快响应可以为保险经纪⼈提供更多的机会以产⽣更多的业务。保险⾏业的保险单承保⼈使⽤潜在客户的驾驶记录作为确定风险的因素之⼀。这第⼀个⽰例演⽰了基于驾驶员的驾驶记录来接受或拒绝投保申请的前端承保筛选条件。
清单 1 显⽰了如何⽤简单的英语来陈述该条件。
清单 1. ⽤于筛选保险单申请的淘汰条件
If a vehicle is registered in California and Driver had 3 accidents in past 2 years
Then
Decline to underwrite or issue an Auto policy.
⽰例 2：分层放置条件
公司罚款单在提交某个保险单以后，通常会基于不同的申请条件将其分类到不同的层中。这有助于承保⼈确定异常的保险单申请。下⼀个⽰例演⽰了⼀个这样的分类。
清单 2 显⽰了⽤简单英语陈述的业务条件。
清单 2. 承保分层放置条件
子宫腺肌症是什么病
If the age of the Driver of vehicle is between 25 and 35
And
If no accidents in past 2 years
Then
Put this Driver in Preferred Tier. (higher discounts by default for this Tier).
⽰例 3：验证/资格条件
索赔处理是保险业的另⼀项重要职能，下⾯的⽰例定义了两个业务决策或操作，如果未在⼀定时间期限内提交索赔申请，则照此决策或操作执⾏。
清单 3 显⽰了⽤简单英语陈述的索赔业务条件。
益达广告清单 3. 保险业中的索赔处理业务条件
追溯的拼音If Claim for an accident is not submitted within 15 days
Then
Do not ttle the claim悟禅
And
Send to manual resolution queue.
上述三个⽰例分别演⽰了什么业务可解释为承保某个保单、基于驾驶记录给予折扣和解决索赔所必需的条件或约束。保险⾏业的全部意义就是管理和最⼩化风险。为实现此⽬的，保险⾏业使⽤软件应⽤程序来系统表达业务条件并⾃动化这些条件，这正是 IT 专家派上⽤场的地⽅。在引⼊ BRMS 以前，IT 完全控制着业务规则的管理，使得事情从最终⽤户的⾓度看来⾮常困难。这样还为造成误解留下了巨⼤的空间，从⽽产⽣管理不善的代码，并最终影响总体业务。⽽且 IT 使⽤某种编程语⾔来实现业务规则。清单 4 显⽰了使⽤诸如 Java™ 等⾯向对象的编程语⾔将淘汰条件（来⾃）编写为结构化逻辑时的代码。
清单 4. 使⽤ Java 语⾔实现的淘汰条件
public String driverKnockOutCheck(Driver driver) {
// The first step is to call another method to calculate the total number
// of accidents in past x number of years.
int numOfAccidents =
calculateNumOfAccidentsInPastNumberOfYears(2);
// Apply the business logic and bad on this t the status of
// policy to APPROVED/DECLINED.
If (numOfAccidents >= 3) {
currentPolicyStatus = DECLINED;
}
return currentPolicyStatus;
}
这个实现并没有什么错误，虽然要更改或管理它不是那么容易。业务还必须寻求来⾃ IT 的帮助来实现任何修改。下⾯是从业务⽤户的⾓度来看，这种⽅法的⼀些缺点：
硬编码的逻辑——可以注意到，诸如年数、允许的事故数量和各种常量等所有参数都硬编码在代码中。⼀旦将此代码编译为可执⾏代码，要对其做出更改将⾮常困难。
特定于语⾔的编码——如该⽰例所⽰，当使⽤任何编程语⾔实现这样⼀个条件时，需要了解该语⾔的专家/程序员才能对业务约束进⾏任何类型的更改或更新。
实现更改所花的时间更长——即使更改单个属性也必须经历软件开发⽣命周期的⼤多数步骤，有时可能要花数周甚⾄数⽉的时间。例如，假设业务分析⼈员决定允许 5 次事故⽽不是 3 次。要做出这个简单的更改，必须经历⼤多数软
件开发⽣命周期步骤，例如开发、QA 和发布管理。
业务⽆法拥有直接的控制——最重要的是，业务⽆法拥有对该逻辑的直接控制，⽽是必须依赖 IT 来做
出任何更改。可以采⽤各种各样的⽅法来⾃动化变更过程，并为业务⽤户提供对这些变更最⼤限度的控制。其中⼀种⽅法是将逻辑定义为 BRMS 中的业务规则。下⼀个部分将探索如何将结构化的逻辑定义为业务规则。
业务规则是什么？
在 Internet 上搜索“业务规则”可以找到许多不同的定义。下⾯是较常见的定义之⼀：“业务规则是对业务的某些⽅⾯进⾏定义和约束的声明”。很简单，不是吗？业务规则⼀般包含⼀组声明性的语句和约束，然后这些语句和约束可以断⾔某些操作或⽬标。简⽽⾔之，业务规则是关于业务操作是“什么”⽽不是业务操作该“如何”。业务规则的主要⽬的是断⾔业务结构，或者控制或影响业务的⾏为。因⽽，规则包含某个“⽤户需求”的正式和可实现的表达，通常使⽤⾃然语⾔（例如英语）以⽂本形式进⾏陈述。
该⽂本形式称为业务规则语句。每个业务规则语句表⽰在运⾏业务当中，⼀个离散、可操作的实践或策略，⽽与任何特定的实现⼿段或特定的技术⽆关。（当然，规则的实际强制⽅式⼀般不应该牵涉到⽤户。）
本⽂开头讨论的淘汰条件规则实际上就是⼀个业务规则，因为它是在强制⼀个业务约束——拒绝⾼风险驾驶员的保险单。
新生儿体重标准
另⼀个淘汰条件
让我们看⼀下另⼀个⽰例，此⽰例说明了⼀个基于驾驶员的驾驶记录来接受或拒绝保单申请的承保筛选条件。⽤简单英语陈述的该条件如清单 5 所⽰。
清单 5. 筛选保单申请的淘汰条件
If a vehicle is registered in California and Driver had 3 accidents in past 2 years
Then
Decline to underwrite or issue an Auto policy.
此⽰例以及上述的所有其他⽰例都是业务规则的例⼦。当使⽤良好的 BRMS 来实现时，可以使⽤简单的英语短语来编写这些规则，就像中的淘汰条件⽰例所⽰的例⼦⼀样。这种类型的熟悉性使得业务策略制定者可以与 IT 紧密配合⼯作。值得重复的是：BRMS ⼯具允许业务⽤户使⽤简单的英语来定义规则。此功能本⾝就是使业务转向使⽤ BRMS 系统的最⼤诱因，因为它给最终⽤户提供了⽆需学习复杂的编程语⾔即可控制业务逻辑的强⼤能⼒。下⼀个部分将探索⼀些其他功能和使⽤ BRMS ⼯具的理由。
BRMS 是什么以及它提供什么功能？
BRMS 是⽤于创建、管理和⽀持企业的业务规则的软件⼯具。它们通过为业务分析⼈员提供对业务逻辑的控制，从⽽在业务和 IT 之间架起⼀座桥梁。其基本思想在于，BRMS 将应⽤程序的业务逻辑与其数据验证逻辑和流程控制分离开来。业务逻辑在⾃⼰的容器（即“规则引擎”）中运⾏，业务分析⼈员使⽤简单的英语式的编程语⾔编写业务规则代码，该代码⾮常容易理解和学习。即使是从来没有使⽤任何编程语⾔来编写过程序的业务⽤户也能够轻松创建和管理这些规则。
图 1 显⽰了BRMS 系统概念上的通⽤体系结构。
图 1. BRMS 系统体系结构
BRMS 系统体系结构
任何⼀流的 BRMS 系统都具有三个主要组成部分。第⼀个部分是 IDE，即集成开发环境（Integrated Development Environment），由 IT ⼈员（主要是规则开发⼈员）⽤于创建必需的框架，以便创建业务和管理规则。第⼆个部分是规则管理应⽤程序（Rule Management Application），这是业务⽤户⽤于创建和更改规则的⽤户界⾯。最后⼀个部分是规则引擎（Rules Engine）本⾝。业务应⽤程序/系统与规则引擎连接，以基于规则存储库中创建的规则来获取⾃动化的决策，其中规则存储库充当规则数据库。
下⾯是⼀些可从 BRMS 体系结构中明显看出的优点，如所⽰。
对于管理企业应⽤程序的必需⾏为⽅式的规则，业务⽤户拥有直接的控制。
⼏乎⽆需与 IT 交互即可修改业务逻辑。
由于规则是使⽤简单的英语式语⾔编写的，业务级别的⼈员更容易理解规则，从⽽改善业务与 IT 之间的关系，缩短实现时间，以及减少发⽣解释错误的机会。
BRMS 还提供了不同的⽅法，可以对规则进⾏分组以便于理解和管理。这样的⼀个规则分组称为⼀个规则集（RuleSet）。规则集是逻辑上具有共同之处的规则的集合。
BRMS ⼯具促进了松散耦合的体系结构。诸如 Blaze Advisor 和 Pega Rules 等⼀流 BRMS 还⽀持⾯向服务的体系结构（Service-Oriented Architecture，SOA）。
BRMS 提供了丰富的开发、测试和⽂档功能，例如：调试、受控的执⾏流、交叉引⽤⼯具和报告⼯具。
更好的规则管理——当您有⼤量的规则需要实现时，BRMS 是更好的选择，因为它能够简化所有那些规则的管理和组织。跟踪、记录和调试问题也更加容易，即使是在规则总数⾮常⼤的情况下。
使⽤ BRMS 的附加优点
由于 BRMS 中的规则是作为⼀个独⽴流程进⾏管理和执⾏的，因此可以将其嵌⼊应⽤程序中或由应⽤程序调⽤，并且⽆需重新编译即可在任何时候更新规则。只要实现⽅式得当，甚⾄可以在不对⽣产系统产⽣流程中断的情况下做出更改。可以对更新后的规则进⾏离线测试，然后按照部署策略（定期发布周期、快速发布更新等等）逐步将其引⼊运⾏的应⽤程序。
有关⼀些领先的 BRMS 产品提供商的列表，请参见本⽂的部分。
IBM 在 BRMS 领域的倡导⼯作——WebSphere Process Server
由于从本⽂开头起⼀直在指出的诸多原因，保险⾏业⼀直在努⼒摆脱其遗留系统：过程代码⾮常难于维护，⽽遗留系统中使⽤诸如 COBOL 等语⾔编写的代码则更加难于维护。IBM ⼀直在积极协助和⽀持从遗留系统迁移到更成熟的系统的⼯作，这些更成熟的系统包含诸如 Java 等⾯向对象的语⾔，同时还包含诸如 SOA 等耦合得更松散的体系结构。WebSphere Process Server 就是 IBM 推出的⼀个这样的倡导⼯作，以帮助包括保险业在内的所有⾏业完成迁移⼯作。
通过使⽤ WebSphere Process Server 来处理包括业务流程管理 (BRMS) 在内的更⼤技术组件，IBM 正在采取⼀种独特⽅法来实现业务规则。WebSphere Process Server 的设计⽬标是成为⼀个完全的业务流程管理（Business Process Management，BPM）解决⽅案，并且业务规则是其中的⼀个主要部分。从技术⾓度看，WebSphere Process Server 是业务驱动的开发流程中产⽣的构件的运⾏时引
擎。WebSphere Process Server 被宣称是下⼀代的业务流程服务器，并⽀持基于 SOA 和开放标准的不同形式的集成。基于服务的模型⽀持跨⼈员、⼯作流、应⽤程序、系统、平台和体系结构的业务流程的⾃动化。图 2 给出了 WebSphere Process Server 平台的概况。
图 2. WebSphere Process Server 平台和作为其主要服务组件之⼀的“业务规则”组件
WebSphere Process Server 平台和作为其主要服务组件之⼀的“业务规则”组件
图⽚来⾃标题为“”的 IBM developersWorks ⽂章。
WebSphere Process Server 中的业务规则编写功能由⼀个基于 Eclip 的桌⾯⼯具提供⽀持。业务分析⼈员可以使⽤该服务器附带的基于 Web 的运⾏时⼯具。该⼯具还独⽴于服务器中的其他服务组件，从⽽允许动态编写规则⽽不会影响其他服务。这是⼀个功能强⼤的 BRMS ⼯具。
总结
业务规则并不是⼀个新思想。⾃从最初在软件应⽤程序中引⼊⼈⼯智能以来，业务规则就已经存在了。但在传统上，业务规则是在过程逻辑中实现的，并深埋在应⽤程序中。此类实现的最⼤问题在于，它们使得规则的强制实施变得⾼度不⼀致，并使得对规则的快速更改⼏乎⽆法实现。我们需要某种完善和成熟的⼯具来减轻此类问题。BRMS 就是这样⼀种充满前景的技术。
