Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.
Why? Separation of rule specification from enforcement concerns[2] ensures that …- The true business intent of the rule itself can be directly validated. Enforcement concerns do not mix things up.
- The greatest degree of business agility is achieved. Changes to enforcement specifications and changes to the rule itself can be made independently.
- The highest degree of re-use is supported. The same rule can be subject to different enforcement specifications at different points of application.
- Who. If responsibility for enforcing the rule is given to some role in the organization, that role should not be mentioned in the statement of the business rule.
- Where. If responsibility for enforcing the rule is assigned to some component of the technical architecture, that component of the technical architecture should not be mentioned in the statement of the business rule.
- When. In general, every business rule applies to multiple events (flash points). However, those events should not be mentioned in the statement of the business rule.
- How. If capability for enforcing the rule is laid out in some process or procedure, that process or procedure should not be mentioned in the statement of the business rule.