2007.12.20更新修正部分文字
分析阶段的Use Case（User Story）除了Business Flow描述外，另一个重要的部分就是业务规则。组织和实现这些业务规则有不同的手段（将带来不同效益）。除传统的开发人员的代码实现外，越来越多系统开始使用规则系统来组织。
对于应用规则引擎网络上著名的有两篇文章：《 Java规则引擎与其API应用详解》和《 企业平台中的业务规则引擎》
此外，JBoss也基于Drools推出了JBPM。Oracle也推出了自己的规则产品。
不过在应用规则引擎前，需要了解四个问题：
第一个问题是：什么算是业务规则？
我以为《Business Rules Applied》一书对Business Rule的分类比较合理：
需要强调一下的是（以下想法十分的不成熟）：
规则中不应该处理业务流程（任何具有实际意义的业务操作），只有规则本身。包括：
A. 不在规则中更新Domain Object的属性；
B. 不访问Dao对象的创建，更新和删除的持久化工作；
C. 不访问Domain Service中任何涉及Domain Object更新、网络访问、文件操作和邮件操作等方法；
D. 只产生提供控制信息或者状态信息等runtime数据，由业务流程来完成A，B和C限制的行为。
第二个问题是：要确定的是否所有的控制逻辑都要用可定制的业务规则来解决？
答案很明显，并非所有的地方都需要。
很多控制逻辑细节都可以采用参数化配置来完成，采用参数配置对于提高性能也有好处。当然参数化配置意味着，对应的控制逻辑的业务边界是确定的。一旦面对高度客户化的业务逻辑，就需要采用规则系统了。
第三个问题是：如果要，那么我们需要一个什么类型的规则系统？
规则系统的分类（以下是我的分类）：
根据功能，规则系统可以分两类：Formula系统和正统的rule系统。我把Formula系统看作是一个弱化的rule系统，只做公式计算，Excel用的最多的功能也是这个。
根据语言，规则系统可以分两类：编程语言系统和类DSL系统。类DSL更接近自然语言，更接近问题描述语言。
根据引擎，又可以分为脚本系统和推理系统。如JRule就同时支持两种技术：checklist和forward chain，当用checklist时就是一个脚本系统。BTW：Ajoo同学的 JASKELL是一个不错的脚本系统。
使用什么的规则系统，取决于系统的需要。
更多的时候系统不需要做推理（因为设计的时候人都做了），一个脚本系统就可以满足需要，而一个弱化后的Formula系统更简单实用。
下面是我在javaeye上开的一个和这个有关的话题：
规则系统or脚本系统，自然语言，DSL or Java语言
第四个问题是：一旦确定了使用规则系统，该系统的受众是谁，即谁使用该系统？
受众是开发人员还是客户将是一个问题。
如果是开发人员，所要做的工作就是把设计好的对象映射到规则系统中，不需要额外的工作。而如果是客户，或许要多做些工作了。
问题的所在是：通常系统设计采用OO原则，而OO追求的是细粒度的设计，这点对于开发人员来说不是什么问题。但对于客户来说则不一样，客户看到的或者说说理解的对象模型（如果他能理解的话）是一个粗粒度的概念。于是我们不得不额外做些工作——封装不同对象（关联的）到一个对象中。
一旦使用了类DSL 的规则系统，我们关心的就不是程序，而是一个问题描述。虽然类DSL规则系统最终将生成程序代码（利用代码生成技术），但是很明显，我们所关心的更接近于Use Case（User Story）。无论是开发人员还是客户都将更容易理解系统的行为。
同样，因为采用的是代码生产技术—— 产生式编程（又拔了一个高度，hoho），综合效益显然（这个……广告语）。更多请参考《产生式编程》一书
分析阶段的Use Case（User Story）除了Business Flow描述外，另一个重要的部分就是业务规则。组织和实现这些业务规则有不同的手段（将带来不同效益）。除传统的开发人员的代码实现外，越来越多系统开始使用规则系统来组织。
对于应用规则引擎网络上著名的有两篇文章：《 Java规则引擎与其API应用详解》和《 企业平台中的业务规则引擎》
此外，JBoss也基于Drools推出了JBPM。Oracle也推出了自己的规则产品。
不过在应用规则引擎前，需要了解四个问题：
第一个问题是：什么算是业务规则？
我以为《Business Rules Applied》一书对Business Rule的分类比较合理：
Constraint |
A constraint can be a mandatory restriction or suggested restriction on the behavior of the business event. A mandatory constraint is a complete statement that expresses an unconditional circumstance that must be true or not true for the business event to complete with integrity. Examples of mandatory constraints are: A customer must not have more than 10 open orders at one time. The total dollar amount of a customer order must not be greater than the customer’s single order credit limit amount. |
Guideline |
A guideline is a complete statement that expresses a warning about a circumstance that should be true or not true. A guideline does not force the circumstance to be true or not true, but merely warns about it, allowing the human to make the decision. Because a guideline only warns and does not reject, it provides a freedom of choice. An example of a guideline is: A customer should not have more than 10 open orders at one time. |
Action enabler |
A complete statement that tests conditions and upon finding them true, initiates another business event, message, or other activity. That is, an action enabler initiates a new action external to the scope of the system or increment under study. Examples of action enablers are: If a customer order is valid, then initiate the Place Order process. If a customer is high risk, then notify the customer services manager. Action-enabler rules can be used in some commercial rules products to create an event-oriented sequence of workflow steps. It may be helpful to think of mandatory constraints and action enablers as opposites. Mandatory constraints stop an event from completing. Action enablers start an event. |
Computation |
A complete statement that provides an algorithm for arriving at the value of a term where such algorithms may include sum, difference, product, quotient, count, maximum, minimum, average. An example of a computation rule is: The total-amount-due for an order is computed as the sum of the lineitem amount(s) for the order plus tax. |
Inference |
A complete statement that tests conditions and upon finding them true, establishes the truth of a new fact. Examples of inferences are: If a customer has no outstanding invoices, then the customer is of preferred status. If a customer is of preferred status, then the customer’s order qualifies for a 20 percent discount. |
需要强调一下的是（以下想法十分的不成熟）：
规则中不应该处理业务流程（任何具有实际意义的业务操作），只有规则本身。包括：
A. 不在规则中更新Domain Object的属性；
B. 不访问Dao对象的创建，更新和删除的持久化工作；
C. 不访问Domain Service中任何涉及Domain Object更新、网络访问、文件操作和邮件操作等方法；
D. 只产生提供控制信息或者状态信息等runtime数据，由业务流程来完成A，B和C限制的行为。
第二个问题是：要确定的是否所有的控制逻辑都要用可定制的业务规则来解决？
答案很明显，并非所有的地方都需要。
很多控制逻辑细节都可以采用参数化配置来完成，采用参数配置对于提高性能也有好处。当然参数化配置意味着，对应的控制逻辑的业务边界是确定的。一旦面对高度客户化的业务逻辑，就需要采用规则系统了。
第三个问题是：如果要，那么我们需要一个什么类型的规则系统？
规则系统的分类（以下是我的分类）：
根据功能，规则系统可以分两类：Formula系统和正统的rule系统。我把Formula系统看作是一个弱化的rule系统，只做公式计算，Excel用的最多的功能也是这个。
根据语言，规则系统可以分两类：编程语言系统和类DSL系统。类DSL更接近自然语言，更接近问题描述语言。
根据引擎，又可以分为脚本系统和推理系统。如JRule就同时支持两种技术：checklist和forward chain，当用checklist时就是一个脚本系统。BTW：Ajoo同学的 JASKELL是一个不错的脚本系统。
使用什么的规则系统，取决于系统的需要。
更多的时候系统不需要做推理（因为设计的时候人都做了），一个脚本系统就可以满足需要，而一个弱化后的Formula系统更简单实用。
下面是我在javaeye上开的一个和这个有关的话题：
规则系统or脚本系统，自然语言，DSL or Java语言
第四个问题是：一旦确定了使用规则系统，该系统的受众是谁，即谁使用该系统？
受众是开发人员还是客户将是一个问题。
如果是开发人员，所要做的工作就是把设计好的对象映射到规则系统中，不需要额外的工作。而如果是客户，或许要多做些工作了。
问题的所在是：通常系统设计采用OO原则，而OO追求的是细粒度的设计，这点对于开发人员来说不是什么问题。但对于客户来说则不一样，客户看到的或者说说理解的对象模型（如果他能理解的话）是一个粗粒度的概念。于是我们不得不额外做些工作——封装不同对象（关联的）到一个对象中。
一旦使用了类DSL 的规则系统，我们关心的就不是程序，而是一个问题描述。虽然类DSL规则系统最终将生成程序代码（利用代码生成技术），但是很明显，我们所关心的更接近于Use Case（User Story）。无论是开发人员还是客户都将更容易理解系统的行为。
同样，因为采用的是代码生产技术—— 产生式编程（又拔了一个高度，hoho），综合效益显然（这个……广告语）。更多请参考《产生式编程》一书