- Toward a Business Rules Methodology
- A Patterns-Based Rules Methodology
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A Patterns-Based Rules Methodology
In the account example, we used object think and common sense to decide which object enforced the business rules. For larger, more complex domains, more rigorous means, such as strategies for mapping rules to objects, are desirable. One way to introduce more rigor is through patterns. Strategies for mapping rules to patterns apply to object models built with those patterns.
Patterns for object modeling a business domain are not the same as design patterns that aim to increase reuse and framework pluggability. Business patterns, also known as analysis patterns, focus on creating an object model that clearly communicates the business requirements. Because business rules are part of the business requirements, the mapping of business rules to objects begins with the object model created by analysis patterns. This analysis object model may be refactored with design patterns to increase its reuse and pluggability; however, the refactoring does nothing to change the mapping of rules to business objects. Refactoring the model merely affects how those objects enforce the rules, possibly by delegating to pluggable helper objects. For these reasons, a business rules methodology includes analysis patterns and strategies for mapping business rules to those patterns.
Collaboration Patterns
Analysis patterns that are capable of supporting a business rules methodology must be comprehensive enough to model all business domains, and must present suitable targets for mapping business rules. After examining hundreds of past analysis-object models, we extracted a core set of 12 irreducible patterns, each involving two objects, that were sufficient for modeling the people, places, things, and events of any business domain. (See Table 1.) Higher order-analysis patterns can be decomposed into combinations of these 12 patterns, which are like "molecules" for building object models and larger patterns.
That 12 object pairs can model all business domains sounds surprising until you considers how people, places, things, and events participate and interact in business processes. A person participates in multiple contexts, which is modeled as an actor with a role for each context. A place locates interactions and can be hierarchical, so a place is modeled within an outer place. A thing has a general and a particular description: an item and specific item, respectively. A thing can also be classified as a member within a group, held as a content within a container, or constructed as an assembly out of parts. An event describes an interaction of a person, as a role, with a specific thing, at a given place. A composite event records an interaction with multiple things, each tracked with its own individual line item. And an event can be followed up by a later event.
Because these 12 patterns describe collaborations involved in typical business processes patterns, they are called collaboration patterns. Collaboration patterns are ideal patterns for a business rules methodology that expresses business rules as constraints on whether two objects can collaborate or cease collaborating. The parallelism of the business rules and the patterns facilitates the development of strategies for mapping business rules to the patterns. These strategies then apply to all object models built with the collaboration patterns.
Table 1 The Twelve Collaboration Patterns
Business Rule Categories
Developing rule-mapping strategies first requires some scheme for categorizing business rules. With proactive rule checking, the categories of rules correspond to reasons why one object would reject another. After reviewing many past business object models, we concluded that there are five categories of business rules. (See Table 2.) Because business objects are responsible for checking their own rules, Table 2 describes the rules in terms of the object doing the checking.
Table 2
Five Categories of Business Rules
|
Type |
Is the potential collaborator the right type for me? |
|
Multiplicity |
Do I have too many collaborations to establish another? Will I have too few collaborations if I remove one? |
|
Property |
Are my property values or the potential collaborator's property values acceptable to a global standard? Are my property values compatible with the potential collaborator's property values? |
|
State |
Am I in the proper state for establishing or dissolving a collaboration? |
|
Conflict |
Do any of my collaborators conflict with the potential collaborator? |
Using Table 2, we can categorize the business rules from the account example. The first rule prohibiting a withdrawal from the wrong customer is a conflict rule. The collaborators of the account, the proper customer owners, conflict with a withdrawal not by one of them. The second rule prohibiting withdrawals for amounts greater than the account balance is a property rule. The account compares its balance to the withdrawal amount, and rejects the withdrawal if it is too large.
Distributing the Work
Distributing the work means deciding which pattern player in the collaboration pair does the work of checking the rule. The answer depends on both the pattern and the type of rule. Table 3 shows the mapping of rule categories to the collaboration pattern players. Explaining how we derived this table is beyond the scope of this article, but here are some general guidelines:
Only one pattern player per pattern checks the type rules.
Most pattern players check their own multiplicity and state rules.
For collaboration patterns involving people, places, and things, rules that involve checking both pattern players go in the more specific (role, specific item), more local (place), or more detailed (part, content, member) pattern players.
For collaboration patterns involving people, places, and things interacting with an event, rules that involve checking both pattern players go in the people, place, and thing pattern players.
Table 3 Mapping Business Rules to Pattern Players
