Decision Model and Notation in short DMN is a novel way to model business decisions. DMN allows capturing and modeling business decisions in a way that is easy to understand with business people and subject matter experts. It is a combination of:
- Decision requirement diagram – DRD
- Decision table
- Boxed expressions
- Friendly Enough Expression Language – FEEL
Decision Requirement Diagram (DRD)
This is a graphical model that allows modeling dependencies between input data, decision, business knowledge and knowledge source.
In DRD, the arrows show the dependencies between different nodes in the model. To put it in a simple way, you can read it as if the output result of some nodes will be passed as the input of the other nodes.
In the table bellow, all the elements on a DRD model are illustrated:
||The act of determining an output from a number of inputs, using decision logic which may reference one or more business knowledge models.
||A function encapsulating business knowledge, in the form of business rules, decision table or analytic model. Some of the tool may not support this element. In such case the decision logic is directly linked to the Decision rather than the business knowledge model.
||The authority for a business knowledge model or decision.
||Information used as an input by one or more decisions. It also denotes the parameters of a Business Knowledge Model.
||Information – input data or decision output – required for a decision.
||The invocation of a business knowledge model.
||Showing the knowledge source of an element or the dependency of a knowledge source on input data.
In decision model and notation, the Decision Table is a tabular form that models rules based on conditions and actions which they are also called inputs and outputs. Decision Table is the default type of modeling business rules in DMN. But if your tools support other ways to model business rules then you can freely use them along side with decision table.
In Decision model and notation (DMN) are a simple two column table and effective way to model business formulas, calculations, values and expressions. And then you can share them across multiple decisions and logic.
Boxed expressions simply allows modeling: constant, values, invocation, formulas… Boxed expressions allows putting together building blocks of logic (i.e. decision table, natural language, flow…) and reuse them over and over again.
Friendly Enough Expression Language
In decision model and notation, FEEL is an expression language for business people. FEEL define a syntax for expressing conditions, actions and formula. Consider FEEL like excel formulas that they allow you formulate your thinking about a domain in a context. FEEL is designed to allow ease of use by business people and subject matter experts.
There are benefits of using decision model and notation over the traditional business rules approach. In the business rules approach, very soon you start thinking about the business rules which they are more about the logic implementation. But decision approach provides a more high-level abstracted layer that allows you to see the big picture first rather than diving deep into implementation and losing the context and overview of the solution.
This change of approach:
- Allows scaling business rules in more manageable, reusable visual approach across applications and processes.
- Allows better communication between business, domain experts and IT by enabling a productive involvement of business people and subject matter experts.
- Allows clearly define decision boundaries and expose the decision as a service with a click!
If your tool supports simulation and execution, error checking at design time and runtime with debugging capability then you will not miss anything from business rules approach, but also will have a better way to reuse and scale your business rules in a systematic way.
Submitted by: FlexRule