usiness Rules are pervasive in software. In fact, in most cases, business rules are the very reason for the existence of most software today. As application architectures become more and more sophisticated, few can disagree with the merits of separating the presentation layer from the business layer or the data layer from the business layer. Yet many applications today are still built with process logic and business rules interwoven within the same business/application layer, which can lead to applications that are brittle, hard to maintain, and resistant to change. In this article, I will explain how to decouple the business rules within your application in a manner that yields high organizational visibility and accountability, and promotes rules as a unit of reuse to help you build applications that are ready for change.
A Little Background
When Rod Paddock and I first started talking about ideas for this article, my goal was to share some of the techniques I have successfully implemented for exposing the Microsoft Business Rules Engine (BRE) via services. Always the wise pragmatist, Rod suggested that I first start with an introduction. If my experience delivering two talks on the subject this year at Austin Code Camp and Desert Code Camp in Phoenix are any indication, he’s probably right. Both sessions were well attended, and most attendees had heard of rule-based engines, but had not taken it much further. This intrigues me, because there is a growing developer community that really understands the benefits of dependency injection, inversion of control, and contract-first development. I think that anyone interested in such techniques should look closer at rule-based engine technology because it is a way to accomplish or, at the very least, compliment many of these techniques. So, while my initial goal of going deeper with the technology will have to wait, I hope that you will discover how valuable (and cost effective) incorporating a rule-based engine into your solution architecture and design can be.
|A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business.|
The Business Rules Group, a non-commercial organization that helps to define and disambiguate the definition of business rules defines a business rule as "a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business." The Business Rules Group further defines business rules as organizational "guidance that there is an obligation concerning conduct, action, practice, or procedure within a particular activity or sphere."
As a practical example, a business rule might read like this:
"If the customer is a preferred member, always apply a 10 percent discount on the total checkout price."
Take a moment and re-read the Business Rule Group's definition above. Using that perspective, the significance of this rule is profound. Even with very little specific knowledge about this business, it's evident that:
- The company sells products or services to individuals.
- Elite customers who hold a membership status are entitled to receive a 10 percent discount on purchases.
This rule is likely part of an organizational customer loyalty and marketing strategy, because the business rule is almost certainly designed to motivate customers to pay an annual premium for membership status. At a minimum this rule governs the activity of purchasing goods by influencing the behavior of preferred members to make higher-dollar purchases, because they'll get a modest discount.
This is only one example. Think about the business rules that govern the applications you've built in the past or the project you are currently on. As developers, we wield incredible power-and responsibilityfor ensuring that these business rules are elicited, developed, deployed, and maintained as accurately and efficiently as possible. As you can imagine from the example, there are a number of team roles that come into the lifecycle of a business rule, yet as developers, we tend to hide these rules in the bowels of code bases that will rarelyif everbe visible to other team roles. Further, when we are asked to change or remove a rule after the application has been deployed we naturally resist. Why? Because change is hard, unless your application is built to evolve.
Still, if there is one area of your application that is almost guaranteed to change, it is the business rules. Business rules need to be dynamic just like the business itself. Rule-based engines let you harness this change by making business rules management completely transparent across all interdependent team roles while providing very high run-time performance. In addition to visibility and performance, rule-based engines support the loosely-coupled integration of business rules into applications that use them.
|Editor's Note: This article was first published in the November/December 2008 issue of CoDe Magazine, and is reprinted here by permission.|