In this post, we are going to show you how to reuse a business decision (complex business rules scenario) so that it becomes a reusable building block of your other business logic (e.g. decision, rules, flow, etc.) models. In a couple of older posts, we discussed how you can model a hierarchical business decision where it is derived from complex business rules. Let's take that as an example and see how we can reuse the decision graph as part of the other business logic (e.g., Flow, Decision Table, Tree, Natural Language, etc.).

Reuse strategy

There are many different ways to reuse a decision graph. It depends on the logic that is reusing it. For example, if a Flow needs to reuse a DRD diagram, then a DRD node would definitely be helpful:

Reuse Business Decision

Question

What if you want to use the whole decision graph as part of another Decision Table or any other type of logic besides a Flow?

If we can make the entire decision model above act as a function expression, then no matter what type of logic is used (i.e. decision table, tree, natural language, etc.), it can reuse the decision by calling it as a simple function call.

Logic as a Function Expression

What we can do is to register the whole business logic (i.e. DRD model) as a function and then the input data of this DRD becomes an input parameter of the function.
This sample decision model is called CalculatePremium and accepts two parameters: car and a list (we call it probList). So, if we register the model as a function then

 CalculatePremium(car, probList)

becomes our function.

Now, by having this model defined and registered as a simple function on the expression level, then we can reuse it in any Decision Table, or other DMN models, and so on… by simply calling the function!

Discount sample

For example, let's say we have the decision graph modeled as a core calculation, and based on some cases (e.g., a customer-related situation) we want to give a discount to some people.

To register it as a function expression, you simply need to add the ruleset or file address of the model (i.e., DRD) in a type parameter definition of the caller logic (e.g., Decision table):
dt-function-drd

Let's say we have this discount business rule:

Discount Policy: If a car Auto Premium is more than 1000$ then apply a 3% discount.

We then model the following decision table:

drd-function-dt2

And as you see in A3 column (action column) we call to the DRD model, and of course, you can still debug and simulate it visually, so you don't miss a thing!

The decision as a Service

Of course, the other option here is to use Decision as a Service, but sometimes we don't want to go over the network and use a service layer integration. In that case, this is a viable option that gives you the power of reusability across all types of logic.

Important Note

The technique that is described here is not only for Decision Model and Notation (DMN) and Decision Table! You can literally use this technique to reuse any business logic as part of any other logic without changing or adding your code-based integration. Simply reference the logic and reuse it. I will show you more of this technique in future posts.

Last updated February 9th, 2022 at 02:50 pm, Published November 24th, 2015 at 02:50 pm