In this post we are going to provide an initial introduction to Monad and see how we can use Monadic Business Rule Expressions in modeling powerful business logic (e.g., rules, constraint, conditions, decisions, etc.), as well as how to express business rules in a Monadic way. The first question is what is a Monad and what is so special about it?
In a very simplistic way, Monads are like pipes that can be connected to each other. You can send a data or information from one end and receive the result at the other end. It’s rather like magic:
Without going into the mathematical side of it, we can go straight to its usage and define it from that point of view. Monads are functions that can be chained, so you can redirect the outputs of one function to the inputs of the others. As a simple example, you can see something like this:
Keep in mind that this is a very simplistic model. Of course, a function can have multiple input sources and multiple outputs, each of which may be used further down the line in other chained functions.
For instance, let’s say you have an input parameter named ‘Input’ into which you need to:
- Apply F1 and then
- Apply F2 with the input of F1’s result
So instead of executing these two:
b = F2 (a, 4, 5, 6)
Note: 1,2,3,4,5,6 are just arbitrary arguments for the sample function’s parameters. That’s just to show you a sample function with multiple input parameters.
Now with use of Monads you can re-write and execute that sequence of multistep functions in one expression such as the one shown below:
Let’s say we have a list of people, as follows:
What we want to do is find duplicate names in the list. Let’s assume we have the list in a parameter (variable) called ‘People’.
|filter (g, g.Count>1)
|select (d, d.Name)
What we do in this expression is:
- Group the list by Name of people
- Then we filter the result of the previous (grouping) Monad (function), where the number of items in the group are greater than one, which means that’s the duplicate
- And then we select that item’s Name
Now let’s say we want to count the numbers of duplicates, we can just chain a new Monad at the end of the expression above:
|filter (g, g.Count>1)
|select (d, d.Name)
If you want to see how this will contribute to your business rules modeling, please have a look at this example in which we used a similar Monadic expression to identify duplicates in a Decision Table and wrote a notification error for the duplicated items.
Now let’s say we have two lists and we want to identify the common names between them:
pepole2 |select (b, b.Name)
The interesting part of this example is that a Monad like Intersect accepts another Monadic expression and the whole expression above is just one unit of execution! What that means is you can use the whole expression as a condition of a rule (e.g., a Decision Table’s condition column). And you make your business rules model much simpler as you reduce the amount of multi-step actions to accomplish a task. Therefore, you can model the intent of the rules rather than the algorithm to implement the logic. If you did not want to use Monad in this expression, then you would have had to use a nested for-each loop, then iterate through the collections and identify what was common between them.
All these groups – Select, Filter, Count and Intersect are Monads that allow us to chain the result of one to the input of the next. There are many other Monads available and in the next post we are going to solve a complex example. So we suggest you familiarise yourself with the available Monads at https://resource.flexrule.com/knowledge-base/expression/#pipe
Monads in business rules simplify your business rules model and make it more declarative.
We are building Monad 101 examples at https://resource.flexrule.com/knowledge-base/monad101/. Please feel free to ask questions by sending us an email.
Last updated October 11th, 2019 at 12:35 pm, Published December 1st, 2015 at 12:35 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.