Decision Model and Notation is a novel approach to business rules and the relationships between rule sets (i.e., Decision table, tree, etc.). However, making a reusable DRD (Decision Requirement Diagram) in Decision Model and Notation (DMN) is very interesting. In DMN, the idea is that users model a Decision Requirement Diagram (DRD) and then share it across many business processes and applications as a single source of truth via a decision service.

So far, in DMN the shareable components between DRDs are decision nodes (i.e., decision nodes) as well as other nodes (i.e., business knowledge and knowledge source). Or at best you can go to a decision service (e.g. a service call). These options are very restrictive, as you cannot share an entire hierarchy of connected decisions (and other nodes). So, what if a DRD (or part of it) needs to be shared across multiple DRDs? After all, service call is not always the best in terms of neither performance, visibility and particularly when it comes to debugging an issue as it becomes a black-box.

DRD's Better Alternative – Decision Graph

A Decision Graph (DG) is a more flexible and advanced form of a Decision Requirement Diagram (DRD).

Let's consider the Decision Graph below, which is designed to calculate the insurance premium for a car.
reusable Decision Graph - SubGraph within a Decision Graph

Car Premium has two decisions: Auto Premium (the red highlight) and Base Premium. As in real scenario complexity of the decision model grows Decision Graph shows a significant advantages over DMN's Decision Requirement Diagram (DRD) by allowing you to refactor the complex decision (Auto Premium) into entirely another sub-graph.

Auto Premium Decision

To refactor this entire red area, simply create a new Decision Graph and drag and drop it into main Decision Graph. No decision service is required. Therefore it is faster (saves the round trip and information materialization). Also easier to navigate, more visible to understand (not a service black-box behaviour).

Let's extract the red piece into another Decision Graph model such as the one shown below:
reusable DRD - Car Insurance using DMN - auto premium component

Now this looks exactly like any other Decision Graph (or DRD) with one root decision called “Auto Premium”.

New Premium Model

In the new version of the main decision model, we replace the red highlight with only one Sub-Graph (a new Decision Graph) node:
reusable DRD - Car Insurance using DMN - simpleified sub drd

This new final model is now much simpler (less complex), cleaner, and easier to understand and maintain as it encapsulated the Auto Premium into a separate decision model rather than implementing it in the main decision model itself.

Characteristics of DecisionGraph

We have to look at Decision Graph new node (Sub Graph e.g. Decision Graph) in two ways:
1. The node behavior itself
2. Its connections in relation to other nodes in the model

Remember, this is just a placeholder for the other extracted, reusable Decision Graph that models the entire Auto Premium decision model. In its behavior, this new node (Sub-Graph) is very similar to a Decision node in the standard DMN when it comes calling decision service but it is local, not a service call. Of course, you can have a Decision Service call as well but in a Decision Graph you can have a local link to other graphs as Sub-Graph so as the other types of decision logic implementation (e.g., decision tables, etc.).


Here are the benefit of this approach:
1. Cleaner models: it makes the main model simpler to understand
2. Reusable Decision Graph: It makes for a more reusable Decision Graph without complexity and bock-box behavior of decision service
3. Better Quality: It makes testing of models simpler, as each sub grah can be tested individually.

Last updated May 15th, 2023 at 04:14 pm Published April 29th, 2016 at 05:38 am