Where do business rules go?
‘Where do I put my business rules and logic? Where does validation fit in?’
I don’t know how often I hear this from clients. It is always asked in one or another during most coaching or development engagements. Sometimes it is because of BizTalk, and other times it is because of Atlas (or some other front end framework).
Our first rule of validation:
‘All validation is done on the server side.’
The business layer is responsible for validating its input. We never trust input coming from outside the business layer. This is a fundamental guideline for application security. Any validation on the web client is purely to support a great user experience. It should definitely be there, but it is just for the user’s needs, not for the system’s needs.
So, where do you put your business rules? As with many things with BizTalk, it depends. The first aspect to consider is how you are using BizTalk in your system. If you are using it as middleware to integrate several different systems (sort of an ESB approach), then your business rules should be used in the systems themselves. You can still use the BizTalk Business Rules Engine, but it should be used from your applications, and not embedded in the messaging layer of your bus.
However, if you are using BizTalk to run your application on as a platform, then there is a continuum for you to consider. The most important aspect to drive where on the line you want to be should be how often these business rules will need to be modified. The more often they change, the more cheaper and easier you want it to be to update them. Remember that a good business changes, and it's systems must support this.
On the far left side is the ‘custom code’ approach. You would bake the rules into your source code. This will give you the best speed of execution, but the worst story for maintenance and management. You will not easily be able to change the rule if you need to, and you will have the cost of moving code changes through your lifecycle (testing, qa, promotion to production, updating support documentation, etc.). This is also the most brittle solution, and will reduce your systems ability to be agile.
The other side of the continuum is to put the rules into the BizTalk Business Rules Engine (BRE) and then access those rules either through orchestrations, web services, or through the BRE API. The API is the fastest, but the web service approach can help you leverage those rules in other places. One of the best advantages to this approach is the centralization of your rules. Keeping them in one place can greatly reduce the cost of maintaining a system. Of course, if you aren't using BizTalk you can still do this, just find another rules engine to use. On our Java projects we use JRules. I wouldn't build something like this when there are so many good alternatives out there already.
In the middle of this continuum is the option to put rules in the orchestrations themselves. This is risky in my view, but an option. I only use it for trivial rules that are truly a workflow routing question. Even if the rule is simple, a tax rate for example, I know that in the future it can grow to be more complex. This approach is less expensive than maintaining code, but more expensive to maintain than the BRE based approach.
I think your decision can be made on a case by case basis as you are building your system, but sticking to one approach will make your system more consistent.
Hopefully this can act as some guidance for you as your design your system. Unfortunately there are rarely hard written rules in architecture. Most decisions come down to a choice, where you need to discuss the benefits and costs of each option. In the end, you should always strive to reduce the system brittleness, the system maintenance costs, and to inhibit ripples that changes cause in the system.
-bhp
Thanks to areyn for helping with this post.
I don’t know how often I hear this from clients. It is always asked in one or another during most coaching or development engagements. Sometimes it is because of BizTalk, and other times it is because of Atlas (or some other front end framework).
Our first rule of validation:
‘All validation is done on the server side.’
The business layer is responsible for validating its input. We never trust input coming from outside the business layer. This is a fundamental guideline for application security. Any validation on the web client is purely to support a great user experience. It should definitely be there, but it is just for the user’s needs, not for the system’s needs.
So, where do you put your business rules? As with many things with BizTalk, it depends. The first aspect to consider is how you are using BizTalk in your system. If you are using it as middleware to integrate several different systems (sort of an ESB approach), then your business rules should be used in the systems themselves. You can still use the BizTalk Business Rules Engine, but it should be used from your applications, and not embedded in the messaging layer of your bus.
However, if you are using BizTalk to run your application on as a platform, then there is a continuum for you to consider. The most important aspect to drive where on the line you want to be should be how often these business rules will need to be modified. The more often they change, the more cheaper and easier you want it to be to update them. Remember that a good business changes, and it's systems must support this.
On the far left side is the ‘custom code’ approach. You would bake the rules into your source code. This will give you the best speed of execution, but the worst story for maintenance and management. You will not easily be able to change the rule if you need to, and you will have the cost of moving code changes through your lifecycle (testing, qa, promotion to production, updating support documentation, etc.). This is also the most brittle solution, and will reduce your systems ability to be agile.
The other side of the continuum is to put the rules into the BizTalk Business Rules Engine (BRE) and then access those rules either through orchestrations, web services, or through the BRE API. The API is the fastest, but the web service approach can help you leverage those rules in other places. One of the best advantages to this approach is the centralization of your rules. Keeping them in one place can greatly reduce the cost of maintaining a system. Of course, if you aren't using BizTalk you can still do this, just find another rules engine to use. On our Java projects we use JRules. I wouldn't build something like this when there are so many good alternatives out there already.
In the middle of this continuum is the option to put rules in the orchestrations themselves. This is risky in my view, but an option. I only use it for trivial rules that are truly a workflow routing question. Even if the rule is simple, a tax rate for example, I know that in the future it can grow to be more complex. This approach is less expensive than maintaining code, but more expensive to maintain than the BRE based approach.
I think your decision can be made on a case by case basis as you are building your system, but sticking to one approach will make your system more consistent.
Hopefully this can act as some guidance for you as your design your system. Unfortunately there are rarely hard written rules in architecture. Most decisions come down to a choice, where you need to discuss the benefits and costs of each option. In the end, you should always strive to reduce the system brittleness, the system maintenance costs, and to inhibit ripples that changes cause in the system.
-bhp
Thanks to areyn for helping with this post.
Comments
also when to use "Decide" shape and "Call Rules" shape. Both serve the purpose of decision(rule) making.
You can achieve what a Call Rules shape does using a Decide Shape. I would use Call Rules for simple, normal access to a rules policy from your orchestration.
If you need more flexibility, you can call the policy through the .NET API in a code block (for example to specify a policy version, or pass a .NET object versus an XML message), and use the results in a decide shape.
You can achieve what a Call Rules shape does using a Decide Shape. I would use Call Rules for simple, normal access to a rules policy from your orchestration.
If you need more flexibility, you can call the policy through the .NET API in a code block (for example to specify a policy version, or pass a .NET object versus an XML message), and use the results in a decide shape.