The Decision Model and Notation (DMN™) is a modelling language notation created by OMG for the specification of business decisions and business rules. In this tutorial we will have an overview of what is DMN and which are the key constructs of this language that you can use to model your Decisions that drive your business.
What is DMN?
Firstly, some basics. DMN is about modelling Decisions in your business in a format which can be understood by business analysts and stakeholders. DMN also aims at providing a formal documentation on how Decisions are implemented for a business activity.
In general terms, the following decisions are part of any business:
DMN is not a replacement for the BPMN Process standard as we will see in the next paragraph.
DMN vs. BPMN
DMN is for Decision Management what BPMN is for business process management. Therefore, it is no surprise that these standards are not incompatible but rather complementary. Indeed, DMN can be an useful extension to the BPMN standard to reduce complexity and optimize your BPMN models, especially at documentation level.
As a matter of fact, if you model your decisions directly using BPMN components you will end up mixing Process flows with Decisions Models which should be transparent to the Processes
Why is important to separate Process models from Decision models?
- Process models focus on orchestration while decisions focus on intelligence and complex business logic.
- Processes are usually stable over months or years while decision logic changes follow a shorter cycle due to new policies or market changes.
- In many cases, processes reuse decisions. The solution is to centralize the management and deployment of decisions to ensure consistency and reduce maintenance efforts.
Drool Rules vs DMN
Before digging into DMN core components, we will clarify what is the difference with Drools Rules (More about Drools here: Drools tutorial – The Rule Engine made simple )
As you know, a Drool Rule (DRL) is a technical rule language, which also enables Complex Event Processing (CEP), and a forward-backward chaining rule style of application. On top of that, with Drools you can describe both stateless or stateful rules in conjunction with guided rules, DSL and Decision Tables.
DMN, on the other hand, is a standard and visual notation for Decision Management. It aims to bridge the gap between business analysts and tech guys, with a well defined execution semantics by a standard specification. Also, DMN introduces an expression language for defining decision logic called FEEL (Friendly Enough Expression Language) . This language aims at better enabling business users to define and understand decision logic.
So, for some aspects DMN overlaps with DRL. But is can be an addition as well: for example you could express stateless decision login with DMN and more complex stateful login or CEP with DRL rules.
This editor allows you to design your Models and to run them as well provided that you have started the DM Runner. The DM Runner is a Quarkus native application which allows to see live forms and results as you edit your DM.
In this tutorial we cover how to design and run your first DM using the KIE Sandbox
Right now, let’s explore the component you can add to your Decision Model:
Let’s see them in detail:
- Input data serves as input for one or more decisions.
- Knowledge source references a real-world factors rather than executable business rules.
- Business Knowledge Model is reusable function with one or more decision elements. The decision logic can hold a FEEL function, a Java method invocation, or a PMML invocation.
- Decision: a Node where one or more input elements determine an output based on defined decision logic.
- Text annotation consists of a square bracket followed by an explanatory text or a comment.
- Decision Service contains a set of reusable decisions published as a service for invocation. You can invoke them from another decision node, or externally by a BPMN process or another DMN model.
Decision nodes are a crucial component of each Model. As a matter of fact, they may express their logic by a variety of expressions::
That’s the simplest decision. They hold a FEEL expression that produces an output value. Example:
if 20 > 0 then “YES” else “NO” “YES”
A Context expression in DMN is a set of variable names and values with a result value. Each key-value pair is a context entry. The following expression calculates the result of an expression based on the Total Points key:
Decision tables are a tabular representation of conditional decision logic. You use decision tables to define rules for a decision node that applies those rules at a given point in the decision model.
Hit policies determine the semantics of a decision table and how rules must be structured. There are two policies:
- Single hit policies Single hit policies considers exactly one rule. However, this rule can produce multiple outputs.
- Multi hit policy Multi hit policies aggregate outputs as sums/ lists.
Relations are a pretty straightforward decision logic. They encapsulate lists of expressions:
Functions define reusable operations into your model. When you can’t or don’t want to use FEEL to express some specific logic, you can also call it from the PMML or Java world. As an example, the following Round function can be used to wrap a call to the java.lang.Math.round method:
It is a tabular representation of how decision logic defined within a Business Knowledge Model (BKM) or a Decision Service is invoked by a Decision or by another Business Knowledge Model. The following invocation expression calls the Calculator BKM to calculate a monthly rate for a loan:
Lists represent a group of FEEL expressions. You may use it to define complex items for a particular decision, like this:
We have covered the basics of DMN, highlighted the main differences with the standard Rules provided by Drools Rule engine and how DMN complements BPMN. In the next tutorial we will see how to create a simple DMN and run it with a Quarkus application: DMN example application with Quarkus