Identify which rules need to be externalized
Rules whose use is limited to a single application, or that change infrequently, are candidates for services that you should NOT externalize.
|
For reactive business rules, identify pertinent triggering events, execution conditions, and actions.
Business rules fall into two broad categories:
-
Inference rules (IF this, THEN that), which are commonly stateless rules that are
encountered during the execution of procedural applications; and
-
Reactive rules, which are triggered by specific events, run if a specific condition is valid,
and which perform a specific action -- such as a database modification. Reactive rules commonly are executed
by a system that monitors its surrounding conditions. As an example, when a particular item in a grocery
store falls below a certain number of on-shelf items, that might trigger a restocking order.
In this step, focus on reactive rules. The triggering event, transition condition, and
action taken need to be documented. If the candidate service is selected later for exposure, these three
items will need to be addressed during the implementation of the service that realizes the rule.
|
Decide which conditions and actions need to be externalized
For reactive rules, the execution conditions and the actions are points of potential variability. They are candidates
for externalization as services. |
Apply the Rule Pattern Language, or similar best practices, to determine rule types and understand how to realize rules.
The Rule Pattern Language [ARS01] defines 21 best practices for categorizing and realizing business rules.
|
Update candidate service portfolio and service hierarchy
Add the new candidate services to the candidate service portfolio. Position them within the candidate service
hierarchy, in alignment with your chosen taxonomic approach. |
|