Business rules

规则对于商业逻辑来说非常重要，OptimalJ能够让企业将业务规则加入到软件开发当中，能够方便地定义和动态地维护它。以业务规则为中心的开发方式的好处是：

• 业务侧：商业逻辑的改变不会破坏软件结构，也不需要花费很多人力去实现它。由于业务规则使用容易理解的方式表示，领域从业人员可以和分析、设计人员一样参与系统规划，通过review活动来使得规则更加精确和完整。最终，由于需求把握准确，系统可以快速分发，维护代价更小。

• 技术侧：这种方式保证了业务规则被以标准的方式实现，在一定程度上填补了项目中需求、分析、设计各个阶段之间存在的鸿沟。使用基于业务规则方式的开发，可以缩短编码和部署的时间。业务规则改变之后，可以很容易地被实现并反映到应用程序当中，因为业务规则被集中保存和维护，且与数据、处理逻辑分离。由于需求会在沟通的过程中不断地提出，这种方式可以使得项目团队通过对业务规则的迭代开发来应对这种变化。

为了实现这种途径，我们必须为企业定义一些业务规则。业务规则是一种描述信息，它定义或者约束了部分业务逻辑。它用于对业务逻辑结构进行验证，用于控制或者影响业务逻辑的行为。业务规则的分类如图所示：

业务规则是term、fact和rule的集合。

• term是一个名词或者名词短语，是对一种共识的定义

例如：一个有效的账户被定义为此账户有余额

• fact 是一个完整的描述，通过动词来连接terms使其成为一个有效的声明

例如：银行客户必须至少拥有一个有效的账户

• Rules 分为三种规则：

– Constraint rules 描述了一种无条件必须为真或者假的强制规则。这种约束可以是结构化的(structural)约束，也可以是行为的(behavioral)约束。

• 结构化的约束：当创建term或者改变term之间的关系的时候，结构化的约束能够保证term的完整性。

• 行为的约束：典型地被定义为“前置条件”和“后置条件”。只有符合“前置条件”的情况下操作才能够正确地执行；“后置条件”保证了操作结果的正确性。

    例如：客户在银行刚开户时余额为0，能够取款之前账户必须有钱。

Computation rules 提供了计算term值的算法

例如：月末账户余额 = 余额 + 余额*月利率

 Conditional rules 基于条件的规则，如果为true，则触发某种事件或者事务。

例如：如果一个账户余额超过100,000美元，则这个客户具有高优先级。如果客户具有高优先级，则提供给此客户金融市场的更多信息。

通过定义terms、facts和rules的集合，我们不需要将业务规则深陷到代码中去，使得它独立出来，能够被不断地重用，也可以迅速地应对需求的变更。为了实现这一愿景，一个企业必须具有一个强大的工具，它能够捕获业务规则，将他们发布到一个中央存储仓库中，以一致的方式自动分发和部署业务规则，让领域从业人员能够监控它的执行。OptimalJ可以做到。

在OptimalJ中定义业务规则

业务规则被加入到模型当中。OptimalJ然后将这些业务规则转换到J2EE应用程序当中，并自动传播到调用它的各个角落。同时，业务规则还在应用程序的各个层次上保持一致。例如，在基于jsp页面的表示层，规则被用来检查账户号码的格式是否正确；在基于EJB的业务逻辑层，规则被用来检查账户号码是否唯一存在；开发人员不再需要做大量的手工编码来在各个层次来实现业务规则。由于业务规则是易于维护的模型元素，开发人员可以通过在模型上加入各种业务规则来对需求变更作出快速响应。

    在OptimalJ中，terms和facts被实现为Domain Model classes和associations。Rules被实现为OptimalJ模型中多个不同的部分。下图是业务规则各个分类和OptimalJ中模型元素的对应关系：

属性约束(Attribute constraints)和表达式(expressions)

结构化的约束规则被定义为Domain模型的属性约束或者表达式，它被用来定义为约束某个属性的terms(图2)。这些terms可以是一个值域、一些常量、表示java代码的表达式，或者是正则表达式(图3)。

操作的前置条件和后置条件

它们定义了行为的约束规则，在Application模型层次上进行前置和后置条件的修改。和其它形式的表达式一样，它们使用常量或者纯Java代码来编写。Application模型中的SessionBean可以从Domain Services或者Expression Library中生成，其包含一些操作。前置条件和后置条件就作用在这些操作上。

Domain Model services

开发人员可以将computation和conditional业务规则定义为Domain Services。Domain Services被传播到Application模型中，作为SessionBean的一个业务逻辑方法。开发人员在Domain模型级别通过声明接口来定义Domain Services。接口中包含参数、参数类型和返回值类型。当我们自动生成代码实现之后，这些方法的接口定义被自动生成，并放置在保护区域(guarded blocks)，由OptimalJ维护。这个方法的真正实现由开发人员在自由区域(free block)中编写代码来完成。开发人员只可以在自由区域增加业务逻辑代码，从模型中重新生成代码的时候，这部分不会受到影响。

Dynamic business rules

如何将业务逻辑和剩余的应用程序逻辑相分离的呢？通过业务规则从应用程序中剥离出来，集中维护和监控，来获取以业务逻辑为中心的开发方式的所有优点。OptimalJ将业务规则保存在一个中心存储仓库中，提供了一个业务逻辑服务器，我们可以通过这个服务器来访问存储仓库。

动态业务规则的概念是OptimalJ的一个核心。上面说明了，业务规则可以被实现为常量、表达式或者是生成的方法中的Java代码。OptimalJ允许这些表达式被静态定义，也允许它们被动态地定义。静态的业务规则缺乏灵活性，且当规则改变的时候可能会带来问题。选择使用静态方式意味着当规则改变时，开发人员需要重新生成、编译和部署代码。为了将规则改变迅速反映到应用程序中去，明智的做法是使用动态方式。动态方式中，业务规则被动态维护在仓库中，它使得开发人员仅在发布阶段需要处理业务规则，而不需要重新生成代码、重新编译和部署应用程序。

Business rules repository

在应用程序的生命周期中业务规则可能会发生改变，如果将业务规则放置在类(classes)当中，那么对它们的修改则会带来高的修改和维护代价。将业务规则集中存储，可以很方便地应对这种改变，而且提高了重用性。

在OptimalJ中，开发人员可以将业务规则保存在一个分离的Expression Library中。通过这种方式，在应用程序的生命周期中我们可以方便地修改和重用业务规则。业务规则仅需定义一次，并且仅需要在一个中心位置对其修改和更新，而不是在整个应用程序中。

Expression Library存在于Application模型中。开发人员将业务规则定义为方法(methods)，它包含参数和返回值，在应用程序中随处都可以调用它。

Business rules server

业务规则服务器提供了在运行时刻对业务规则的动态访问权。原来，业务规则被坚固地嵌入到应用程序的各个角落，修改起来非常不便。现在可以通过动态业务规则来改变这种状况，用户可以在商业逻辑变更时方便地修改它们。开发人员可以同时修改多个规则，它们会被自动分发到应用程序中调用的地方，而不需要重新编译和部署应用程序。业务规则成了一种提供应用程序适应性和灵活性的一种手段。

在OptimalJ中，动态的业务规则可以很容易地创建。当我们在Expression Library中定义了一个业务规则的时候，仅需要将它的“dynamic”属性值设置为True。之后，实现这个业务规则的Java代码就会被自动翻译(translated)并被存储到业务规则仓库中。业务规则仓库是一个XML文件，它包含所有实现业务规则的表达式。XML文件中的业务规则可以在部署阶段被修改，并反映到应用程序中去。

OptimalJ提供了一个业务规则服务器用于提供对动态业务规则的访问。当应用程序需要执行一个规则的时候，他将从服务器中取得规则。这在每次需要执行规则的时候都会发生，而不管是哪个层(表示层、数据访问层)。

当规则被调用时，业务规则服务器适用动态的Java绑定(dynamic Java binding)来解释规则。业务规则可以在部署阶段被修改，而不需要重新编译和部署应用程序。允许企业定制它们自己的规则，OptimalJ使得企业能够迅速地根据客户需求来更改系统，而不是总是等待下一版本的发布。这戏剧性地减轻了维护和增强系统所带来的成本。

Compuware products

Conclusion

OptimalJ提供了如下一些特性来帮助企业采用业务规则途径来进行应用程序的开发：

• 在模型级别而不是代码级别定义业务规则

• 从模型中定义的业务规则中自动生成商业逻辑代码

• 将业务规则集中存储在仓库中

• 通过业务逻辑服务器动态访问业务规则

业务规则开发途径使得business users和technical users能够容易地捕获、发布和维护从地层代码中分离出来的商业逻辑。n