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:

Decision Model and Notation in action

Employee vacation days in DMN – Decision Requirement Diagram (DRD)

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.

Base days

Every employee receives at least 22 days.

DMN decision table

Base 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 3 days vacation

Extra 3 days vacation

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.

DMN decision table

Extra 5 days vacation

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)

Decision table in DMN

Extra 2 days eligibility

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:

Decision model and notation with decision table

Total vacation days based on other decision tables

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).
DMN aggregation function
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.