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.).
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:
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
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!
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):
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:
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.
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
CEO and the founder of FlexRule – He is an expert in architecture, design, and implementation of operational decisions, business rules, and process automation. Created Decision-Centric Approach, a methodology that brings People, Data, Rules, and Processes together to automate operational business decisions.
This approach is recognized by Gartner as the missing link to provide business value to organizations.
Leave A Comment
You must be logged in to post a comment.