Decision model and notation (DMN) is a nice way to model policies and make sure your business rules are implemented properly. Unlike the traditional approach to business rules in which the focus is on the rules themselves, in DMN we start from decisions.
Let’s work on a tangible example. In an employee benefits and entitlement system you would have many rules, some of which are designed to calculate employee vacation days. Let’s say your company has the following policy*:
Every employee receives at least 22 days. Additional days are provided based on the following criteria:
1. Only employees younger than 18 or at least 60 years of age, or employees with at least 30 years of service, will receive 5 extra days.
2. Employees with at least 30 years of service and also employees of 60 years of age or more will receive 3 extra days, in addition to any extra days already given.
3. If an employee has at least 15, but less than 30 years of service, 2 extra days are given. These 2 days are also provided for employees of age 45 or more.
These 2 extra days cannot be combined with the 5 extra days specified above.
(* The policy example was provided by Prof. Jan Vanthienen)
Now let’s have a look at the model below:
Each of the blue rectangles are called “Decision” and each line with an arrow shows the dependence of each decision to another, or to an input data (i.e., employee in round rectangle with pink color).
Now we need to build a couple of simple decision tables and then associate each of them to an appropriate decision node in the above decision requirement diagram.
Every employee receives at least 22 days.
Extra 3 Days rules
Employees with at least 30 days of service and also employees of age 60 or more, receive 3 extra days, in addition to the possible extra days already given.
Extra 5 days rules
Only employees younger than 18 or at least 60 years of age, or employees with at least 30 years of service, will receive 5 extra days.
Extra 2 Days rules
If an employee has at least 15, but less than 30 years of service, 2 extra days are given. These 2 days are also provided for employees of age 45 or more.
These 2 extra days cannot be combined with the 5 extra days specified previously. (This part is handled when we add up all the values in total vacation days)
Total vacation days calculation
In the upper left hand side decision, we calculate the total days based on eligibility for base days and extra days:
We also set the last table aggregation method to Sum based on Rules Order. So the result will be sum of the last column (Vacation Days).
Decision Model and Notation defines a couple of standard aggregation functions.
Benefits of this Approach
If you model only the Decision Tables, for a slightly more complex policy you will lose the big picture and will have no clue about the whole policy scenario that is covered. But by using the Decision Model and Notation (DMN), you start from top, and then drill down to each decision implementation (Decision tables) or other types of logic.
The other benefit is that this approach totally increases your business agility. You can deliver it as a service as soon as your model is ready! And every application and process can use it as simply as calling to a REST API.
The DMN model is not just a picture! it is the big picture and on top of this, the whole scenario including the decision model and notation are executable. You just need to integrate it into your application. In the next post we are going to test and simulate this model and integrate it into a web application.
Last updated January 14th, 2020 at 07:43 am, Published February 1st, 2016 at 07:43 am