Programming with the Microsoft Business Rules Framework : Page 4
Learn how to decouple the business rules within your application to yield high organizational visibility and accountability.
by Rick Garibay
Dec 30, 2008
Page 4 of 9
As discussed, it takes much more than sheer programming to build a software product. One of the main objectives of the Microsoft Business Rules Framework is to help lubricate communication and collaboration between team members in various yet intersecting roles. By using the Business Rules Composer, all team roles can work together to implement the rules as part of a policy that makes sense in a business context, and which is verifiable and traceable by all. While I will not go on a rant about the merits of Domain-Driven Design here, the power of sharing a common language and taxonomy with your entire team is a tremendous boost to productivity, comprehension, and morale.
After authoring and testing, rules and policies can be deployed in a development environment by anyone with access to the Business Rules Composer. However, in staging and production environments, it is likely that a release engineer or an administrative member of a deployment team will be responsible for pushing out new policies and updated existing policies by introducing a new policy version. This is precisely what the Deployment Utility is for.
Coming to Terms
I have already briefly covered many of the following terms in this discussion, but here are some more precise definitions for clarity's sake. After reading this article, you should be well versed in the lingua franca that makes up the Microsoft Business Rules Framework.
Policy: A Policy is a versioned logical grouping of rules. It is represented by the Policy class, which allows a calling component to execute a corresponding rule set bound to the policy. For example, a discount policy would consist of rules about how and when to apply discounts to purchase orders. You create a Policy using the Business Rules Composer, and execute a policy via the Policy class. Policies are versioned; after a version has been deployed, the policy is immutable. This ensures that a policy version remains sacrosanct, and also enables support for concurrent policy versions.
Rule: A rule is a statement that consists of a condition and actions. Rules are commonly created within the Business Rules Composer. A rule consists of a condition that evaluates facts and a corresponding action to take if the condition evaluates to true. In the canonical example, when the preferred member condition is met, the corresponding action will be to apply a 10 percent discount to the purchase. It is possible to program directly with the Rule class, but in this article you will build rules using the Business Rules Composer and execute rules by using the Policy class.
Condition: A condition simply consists of predicates that apply to a fact. Evaluating a condition always returns true or false. Examples of predicates are between, greater than, less than, equal to, and so on.
Facts: Fundamentally, a fact is in-memory data acted upon within the BRE. For example, a Customer object is a memory type that contains information about a customer. The information is represented as public properties, such as First Name, Last Name, and Preferred Member. In rule terms, these fields are referred to as “fact slots,” which are then used in conjunction with a condition and action to form a rule. In the example, the “preferred member” fact would map to the Preferred Member fact slot on the Customer fact.
Fact Types: There are actually two types of facts. Short-term facts are passed into the Policy object and removed from memory as soon as a policy completes execution. Short-term facts are introduced to the Policy class as .NET objects, XML document instances, or database rowsets. Long-term facts remain in memory across multiple execution cycles. An example of a short-term fact might be the Customer instance passed into the Policy instance, while a long-term fact might be the standard shipping rate to apply. Since the standard shipping rate seldom changes, this is an excellent candidate for a long-term fact. In addition, long-term facts can be configured to refresh the cache as necessary.
Actions: An action is the consequence of a rule being executed within a policy that yields a true condition evaluation. The action results in a function call wired up within the Rules Engine Composer. For example, given a customer who is a preferred member, the action may be to set the Discount Percentage field on the Customer fact itself. This is just one of several possible actions.
Vocabulary: A vocabulary is simply a set of user friendly business definitions in the language of the domain that map to a fact or fact slot. For example, in SQL, SELECT MembershipStatus from Customers WHERE LastName= "Deniro" might represent the preferred member status of a customer. While this concept may be pretty straightforward, the T-SQL syntax may not be as intuitive for non-developers. You can use a vocabulary to define the fact and give it a friendly name such as MemberStatus. Now both developers and non-developers can have domain-specific conversations in building a business rule around pricing models for customers who are members.