How can business rules be centrally organized to avoid redundant rules and unintended dependencies?
When placing rules into a single location (rules centralization), this does not control to what the rules apply or how these rules interrelate. The constant risk of creating duplication or overlapping rule boundaries exists, which affects the amount of attainable rule reuse.
Additionally, rules are managed separately from their service context. This is because the logic has been decentralized due to the separation of core service logic and rules.
As time progresses the rules are being used and reused many times in different contexts and for different purposes, resulting in a situation whereby making changes to a rule may have cascaded effects in services where it is least expected.
Design and implement rules while respecting rule boundary alignment.
Functional rule boundaries are aligned as part of the analysis and modeling process.
Appropriate governance must be applied to changes in the rules inventory to allow for persistent application of this pattern.
Extra up-front analysis and design effort is required to ensure that rules remain aligned.
PrinciplesService Loose Coupling
ArchitectureService Inventory, Service
Table: Profile summary for the Rules Normalization pattern.
Even within a centralized rules inventory, when services are delivered by multiple projects or project teams, the constant risk of delivering overlapping functionality and business context in rules exists.
This leads to denormalized rules in the inventory which causes several issues:
- rules sets supporting the same business process in different ways
- duplicate rules with only marginally different purpose causing misunderstanding when to use existing services or creating new ones.
Since service logic is denormalized (centralized rules are managed separately from the core service logic of the services consuming the rules), as time progresses and more and more projects add rules to the rules inventory, managing the rules and understanding dependencies becomes more and more difficult. This may result into a situation with convoluted rules where the consequences of making changes to rules are not easily understood, and can unexpectedly cascade behavioral and functional changes to unintended rules consumers and business processes.
Figure 1 - Rules are used and reused by various services in different contexts which creates (indirect) coupling) between services. Making a rule change for one service may result in unexpected behavioral change in another service.
Recognize that rules have a functional boundary and make sure that these functional boundaries are respected. Rules should not have overlapping boundaries as this is what creates unintended indirect service coupling. Governance to respect the functional boundaries ensures that rules remain as reusable as possible.
Figure 2 - Rules defined in the service inventory are, after being centralized, abstracted into logical rule units with a clear boundary. Rules boundaries must not be (not even partially) overlapping, unless explicitly necessary for the rules context. Refer to the rule layers pattern to see how to deal with intended overlapping rules boundaries.
Functional rule boundaries are modeled as part of the analysis and design process. Appropriate governance is necessary to make sure that in all current and future efforts, the boundaries of existing rules are respected, and new rules are being created with appropriate boundaries.
Respecting functional boundaries of rules requires more up-front modeling effort at design time, but pays off because of a reduction in analysis time of rules when changes or additions are required.
Governance is required to ensure all current and future initiatives on the rules inventory respect the rule boundaries.
(Rules) normalization is a term borrowed from the databases domain and applies to rules in a similar way that it applies to database and service functional context. Similarly, rules normalization defines that the amount of (functional) redundancy across rules is minimized. Similarly to service normalization, this pattern supports the separation of concerns.
By normalizing rule definitions, more rule reuse potential is created. Rules centralization is a direct prerequisite for normalization to work.
As more system resources are claimed by creating more normalized rules, the autonomy of the services executing the normalized rules is affected.
The Rules Normalization pattern is a prerequisite for the Rules Layering Pattern.
Figure 3 - Rules Normalization helps increase service loose coupling at the cost of service autonomy. Service normalization is supported by normalizing rules context. Rules centralization is required to implement normalization.