The document outlines guidelines and best practices for designing business rules in application architecture, emphasizing the separation of business procedures from business rules. It discusses the structure of business rules, their role in decision-making, and the importance of using a rules engine for execution. Additionally, it contrasts business rules with validation checks, advising against modeling simple validation checks as business rules due to their static nature.

1. Rule Design Guidelines and Best Practices
1
Keshav Deshpande
Software Developer
kdeshpande1@verizon.net

2. • Application Architecture with Business Rules
• Separating Business Procedures from Business Rules
2
• Structure of a Business Rule
• Anatomy of Rule Execution
• Business Rule Modeling, Best Practices and Guidelines
• Business Rules vs Validation Checks
Topics

3. Application Architecture with Business
3
Rules

4. Application Architecture with Business
4
Rules

5. Application Architecture with Business
5
Rules
• Business procedure/workflow distinct from Business Rules
• Business Rules hosted and executed within rules engine
Implications
 Separation of concerns
• generally accepted as good application design pattern
 Business rules can be independently modified
• Modifications done outside of application code
 Business Analysts can access/simulate/run/test Business
Rules
• in isolation from application

6. Business Procedure Vs Business Rules
6
Example Business Procedure:
An incoming claim is routed to appropriate claim processor
team, based on claim amount
Example Business Rule:
claim amount is greater than $10000
route claim to Team A
Vs.

7. Structure of a Business Rule
claim amount is greater than $10000
7
route claim to Team A
A rule
 is a Declarative Expression comprising of –
and
 can have multiple (and-ed/or-ed together)
multiple (and-ed together)
Rules can be grouped together –
expressed as or
Assertion
Action

8. Anatomy of Rule Execution
A Rules Engine is a
• ‘Fact-Assertion-Action’ engine (forward-chaining inference)
• Container for rule execution
8

9. Anatomy of Rule Execution
A Rules Engine is a
• ‘Fact-Assertion-Action’ engine (forward-chaining inference)
• Container for rule execution
9

10. Business Rule Modeling
 Mining Business Tier for Business Rules
• Harvesting Business Rules – highly analytical, cross-functional
team undertaking
 Segregate Business Procedures from Business Rules
 A Business Rule exists to facilitate Business Operational
Decisioning
• imperative - frequent modifiability
 Business Rules provide control and governance
• “way-we-do-business”
• influence behavior of business
10

11. Business Rule Modeling
Frequently encountered question:
What about validation check “rules”?
Examples:
• social security number validation
• telephone number validation
Can I implement validation check routines as “business rules”?
You can, but should you?
11

12. Business Rules Vs Validation Checks
Business Rule Validation Check
• Strategic, ‘big picture’
connotation
• Business decision-oriented
• Frequently modified
• Modifications – consequence of
dynamic operational
environment
• Influences “way-we-do-business”
 Validation checks best NOT modeled as business rules
 If you absolutely have to - use the ‘frequency of modification’ as final
12
decision point
• Tactical, narrow focus
• Data-oriented
• Not modified as frequently
• Modifications are aspect of
data governance
• Amount to pass/fail checks,
failures equate to errors

13. Business Rule Modeling
Generally, these are NOT good Business Rules candidates:
After all, why use a Rules Engine to execute –
 Logic that is not likely to ever change, once implemented
 Logic that does not have “way-we-do-business” connotations
 Database lookups, data validation checks
 Data transformations, long-running processes
 Logic that has little influence over business operational
13
behavior

14. 14
Thanks!
Please stay in touch at - kdeshpande1@verizon.net