Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Business Rules - Design and Modeling Guidelines


Published on

A primer on influence of business rules on application architecture, a brief guideline on rules modeling and design.

Published in: Software
  • Login to see the comments

  • Be the first to like this

Business Rules - Design and Modeling Guidelines

  1. 1. Rule Design Guidelines and Best Practices 1 Keshav Deshpande Software Developer
  2. 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. 3. Application Architecture with Business 3 Rules
  4. 4. Application Architecture with Business 4 Rules
  5. 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. 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. 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. 8. Anatomy of Rule Execution A Rules Engine is a • ‘Fact-Assertion-Action’ engine (forward-chaining inference) • Container for rule execution 8
  9. 9. Anatomy of Rule Execution A Rules Engine is a • ‘Fact-Assertion-Action’ engine (forward-chaining inference) • Container for rule execution 9
  10. 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. 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. 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. 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. 14 Thanks! Please stay in touch at -