这是 Mdasky中的译文： OptimalJ的业务规则 的一个概要：
一，业务规则的描述方式
业务规则是一种描述信息，它定义或者约束了部分业务逻辑。它用于对业务逻辑结构进行验证，用于控制或者影响业务逻辑的行为。业务规则的分类如图所示：
业务规则是term、fact和rule的集合。
term是一个名词或者名词短语，是对一种共识的定义
例如：一个有效的账户被定义为此账户有余额
fact 是一个完整的描述，通过动词来连接terms使其成为一个有效的声明
例如：银行客户必须至少拥有一个有效的账户
Rules 分为三种规则：
1、Constraint rules 描述了一种无条件必须为真或者假的强制规则。这种约束可以是结构化的(structural)约束，也可以是行为的(behavioral)约束。
2、 结构化的约束：当创建term或者改变term之间的关系的时候，结构化的约束能够保证term的完整性。
3、 行为的约束：典型地被定义为“前置条件”和“后置条件”。只有符合“前置条件”的情况下操作才能够正确地执行；“后置条件”保证了操作结果的正确性。
例如：客户在银行刚开户时余额为0，能够取款之前账户必须有钱。
Computation rules 提供了计算term值的算法
例如：月末账户余额 = 余额 + 余额*月利率
Conditional rules 基于条件的规则，如果为true，则触发某种事件或者事务。
例如：如果一个账户余额超过100,000美元，则这个客户具有高优先级。如果客户具有高优先级，则提供给此客户金融市场的更多信息。
通过定义terms、facts和rules的集合，我们不需要将业务规则深陷到代码中去，使得它独立出来，能够被不断地重用，也可以迅速地应对需求的变更。为了实现这一愿景，一个企业必须具有一个强大的工具，它能够捕获业务规则，将他们发布到一个中央存储仓库中，以一致的方式自动分发和部署业务规则，让领域从业人员能够监控它的执行。
二、 业务规则到Application模型的映射
在OptimalJ中，业务规则可以应用在应用程序的各个层次上，如：在基于jsp页面的表示层，规则被用来检查账户号码的格式是否正确；在基于EJB的业务逻辑层，规则被用来检查账户号码是否唯一存在。
在OptimalJ中，terms和facts被实现为Domain Model classes和associations。Rules被实现为OptimalJ模型中多个不同的部分。下面是一些典型的映射处理：
1，属性约束(Attribute constraints)和表达式(expressions)
结构化的约束规则被定义为Domain模型的属性约束或者表达式，它被用来定义为约束某个属性的terms。这些terms可以是一个值域、一些常量、表示java代码的表达式，或者是正则表达式。
2，操作的前置条件和后置条件
它们定义了行为的约束规则，在Application模型层次上进行前置和后置条件的修改。和其它形式的表达式一样，它们使用常量或者纯Java代码来编写。Application模型中的SessionBean可以从Domain Services或者Expression Library中生成，其包含一些操作。前置条件和后置条件就作用在这些操作上。
3，Domain Model services
开发人员可以将computation和conditional业务规则定义为Domain Services。Domain Services被传播到Application模型中，作为SessionBean的一个业务逻辑方法。开发人员在Domain模型级别通过声明接口来定义Domain Services。接口中包含参数、参数类型和返回值类型。当我们自动生成代码实现之后，这些方法的接口定义被自动生成，并放置在保护区域 (guarded blocks)，由OptimalJ维护。这个方法的真正实现由开发人员在自由区域(free block)中编写代码来完成。开发人员只可以在自由区域增加业务逻辑代码，从模型中重新生成代码的时候，这部分不会受到影响。
三、OptimalJ中的业务规则服务器
1，Dynamic business rules
选择使用静态方式意味着当规则改变时，开发人员需要重新生成、编译和部署代码。为了将规则改变迅速反映到应用程序中去，明智的做法是使用动态方式。
2，Business rules repository
在应用程序的生命周期中业务规则可能会发生改变，如果将业务规则放置在类(classes)当中，那么对它们的修改则会带来高的修改和维护代价。
在OptimalJ中，开发人员可以将业务规则保存在一个分离的Expression Library中。Expression Library存在于Application模型中。开发人员将业务规则定义为方法(methods)，它包含参数和返回值，在应用程序中随处都可以调用它。
3，Business rules server
业务规则被坚固地嵌入到应用程序的各个角落，修改起来非常不便。现在可以通过动态业务规则来改变这种状况，用户可以在商业逻辑变更时方便地修改它们。
在OptimalJ中，动态的业务规则可以很容易地创建。当我们在Expression Library中定义了一个业务规则的时候，仅需要将它的“dynamic”属性值设置为True。之后，实现这个业务规则的Java代码就会被自动翻译 (translated)并被存储到业务规则仓库中。业务规则仓库是一个XML文件，它包含所有实现业务规则的表达式。XML文件中的业务规则可以在部署阶段被修改，并反映到应用程序中去。
OptimalJ提供了一个业务规则服务器用于提供对动态业务规则的访问。当应用程序需要执行一个规则的时候，他将从服务器中取得规则。这在每次需要执行规则的时候都会发生，而不管是哪个层(表示层、数据访问层)。
当规则被调用时，业务规则服务器适用动态的Java绑定(dynamic Java binding)来解释规则。业务规则可以在部署阶段被修改，而不需要重新编译和部署应用程序。
小结与简评
依我的看法，OptimalJ在处理业务规则到Application的映射时，显得很罗嗦。由于UML表达业务逻辑本身很复杂，再加杂上业务规则在其中，这对领域工程师有很高的要求。
不过，搞一个统一的规则库，则是一个很好的常规的做法。