This month DMCommunity.org asked to present the best design of the notorious decision tables offered by Prof. Jan Vanthienen. It should implement the following business logic:

This problem is not as simple as it looks like from the first glance as it provokes a naive user to add some days several times.

We suggest two designs: one for single-hit decision table and one for multi-hit decision table.  Here they are:

1. Single-Hit Decision Table

Note that instead of the intervals like [45..60) OpenRules allows you to write something like “greater or equal to 45 and strictly smaller than 60”.

2. Multi-Hit Decision Table

The first (single-hit) design is included in our standard OpenRules distribution. But I also wanted to try a multi-hit solution, and I have to admit that initially I made several mistakes that usually only over-confident novices make. It is a good thing that OpenRules allows us to present test cases with expected results. When OpenRules finds mismatches, it immediately points to them. Looking at the automatically generated HTML-reports it was easy for me to find the rules that were applied unexpectedly.

So, the multi-hit solution looks to be closer to the problem formulation and seems to be easier to make changes in this formulation. However, it is more error-prone to compare with the single-hit solution. Of course, we will leave to Jan Vanthienen to choose the best design (probably provided by other vendors).

A Third Solution added on January 12, 2016.

After I published my two above solutions, Gary Hallmark from Oracle offered his DMN-based solution with an essential use of the FEEL formulas and boxed expressions. What I like about Gary’s solution is a separation of concerns – he suggested to have 3 separate decision tables for all 3 extra days eligibility conditions and one more table (boxed expression) for pure arithmetic calculations. What I do not like about Gary’s solution:

1. The use of the following formula:
   Base Days + (if Extra 5 Days then 5 else 0) + (if Extra 3 Days then 3 else 0) +(if Extra 2 Days and not(Extra 5 Days) then 2 else 0)
2. Strangely looking “boxed expressions” which include resulting columns without a title like the one below:It is also not clear why the default result is false (because it is underlined? If “yes”, sorry I had no idea that this is a new DMN 1.1. “feature”)
3. A “magic” character “A” that stands for “Any” single-hit policy (I needed to search inside the DMN specification to refresh my memory) with unnecessary rule numbers. Hopefully, a future DMN will clear up this topic one day.

So, I decided to add a similar solution in OpenRules but without these unpleasant (of course, from my perspective) constructions. Like in Gary’s case, it will be more lengthy to compare with my previous  single tables (single-hit or multi-hit).

Here are new decision tables:

As you can see, I explicitly added 3 intermediate variables: Eligible to Extra 5 Days, Eligible to Extra 3 Days, and Eligible to Extra 2 Days.  The first multi-hit decision table does simple calculations based on combinations of these variables. The next 3 single-hit decision tables set these variables (without worrying about adding days to the total Vacation Days). The nice thing about this OpenRules-based approach is that it uses only standard decision tables: not need for a nice (but tricky) FEEL formula; the default settings are explicit.

Of course, I also needed to add these 3 variables to the Glossary and Data tables for testing. And finally, I added 3 lines to the main decision to explicitly invoke these 3 new decision tables.

Naturally, all these additions make a new multi-table solution more complex to compare with a single table, but it may be more flexible when you consider potential changes in the business logic. At the end of the day, in real-world cases it is a good thing for a user to be able to choose among different options – based on the actual knowledge of the context s/he will choose the best one.