Airlines discount policies are usually more complex than quantity discounts. They depend on when and where you fly, passenger age and couple of other business rules. Let’s consider the following discount policy:
- Passengers older than 18 with destinations in India are offered a discount of 20%, as long as the departure is not on a Monday or Friday.
- For destinations outside of India, passengers are offered a discount of 25% if the departure is not on a Monday or Friday.
- Passengers who stay at least 6 days at their destination receive an additional discount of 10%.
- Passengers older than 2 but younger than 18 years are offered a discount of 40% for all destinations.
- Children 2 and under travel for free
Let’s create an ASP.NET MVC 5 web application. After doing a boring layout job, the page looks like the one below:
This lets users enter their information in the first column, and when they press the “I Feel Lucky!” button the results appear in the last column (Eligibility). This web application has two main functions:
1. Protecting the decision-making process through validation rules to make sure the data that is passed to a decision is in a valid state.
2. Implementation of policy and business rules
Validation is a simple model that you can see in the project source code.
Let’s look at policy implementation. If you were going to implement this policy in code (hard-coding the policy, or even putting some values in a configuration file), make sure you cover all 24 rules! To know why there are 24 rules, please have a look at http://wiki.flexrule.com/index.php?title=Preparing_decision_table.
Yet because you are smart and you develop a smart application, you know this policy may change next season. Not only the rates and values, but also the entire structure and discount calculation within the policy may change. So having some values in a configuration file does not really help.
So let’s use a business rule engine – (FlexRule Decision Engine in our case) – and see what it looks like.
You can use a spreadsheet (e.g., MS Excel) to model the decision. This looks like the one shown below:
Or you can use FlexRule Designer to build a Decision Table (shown below):
And that’s all you need to do as far as policy and business rules implementation.
Now when users press “I Feel Lucky!”, if no information is entered you will get an error list in the third column below:
So the validation kicks in and fills a list of errors to be fixed by users in order to proceed with their request.
And when all required information is entered and users press “I Feel Lucky!”, they may not be eligible for a discount:
Or they may be eligible for a discount (shown below):
But hang on a minute, surely in your logging system you want to know why this conclusion was reached (10% discount), right?
That’s easy! With one line of code you get the information. This sample application prints on the output window (shown below):
You can record it anywhere you like. So now you know the exact reason why this conclusion was reached.
Putting values in a configuration file or hard-coding policy decision logic is not an answer, because it becomes part of main application. When policy changes, your application needs an update. Then it should go through the whole life-cycle of development: Planning, Developing, Testing (Unit, Integration, Functional, etc.), QA Acceptance, Regression Testing and so on.
The benefit of this implementation is that when a business rule is changed, or the policy is updated, or other conditions and criteria are added, your MVC 5 Web Application remains the same. No change in your source code at all! You just need to update the decision model. Above all, you can also track why a specific conclusion was reached simply and effectively.
Please feel free to download the latest FlexRule Runtime at http://download.flexrule.com and look at the samples folder for “Airline Discount Program”.