Clean Code: Domain Driven Design with Decision Tables and Tuple Patterns
- Marcos Jonatan Suriani
- Dec 7, 2022
- 3 min read

For years I have been facing situations in which the domain rule (aka business rule) when written in natural language, either for acceptance criteria or documents, tends to be complex to read. There are cases where this natural writing even has a writing pattern - like Given-When-Then, however the problem persists!
When business rules have decision-making and are converted into source code, conditionals and flow deviations tend to be implemented, which tends to make the code more difficult to read and to maintain, mainly due to inherent characteristics of cyclomatic complexity.
To exemplify, consider the following business rule written in the Given-When-Then pattern:
Feature: Discount on subscribing to a plan on the platform Scenario: Residence in Country with Benefits Given that the user resides in a country with benefit When you sign up for any plan and use Annually or Monthly Payment Then apply 50% off Scenario: Padawan Plan with Monthly Payment Given that the user does not reside in a country with a benefit When signing up for the Padawan Plan and using Monthly Payment Then apply 10% discount Scenario: Padawan Plan with Annually Payment Given that the user does not reside in a country with a benefit When you sign up for the Padawan Plan and use Annually Payment Then apply 15% off Scenario: Jedi Master Plan with Monthly Payment Given that the user does not reside in a country with a benefit When to sign up for the Jedi Master Plan and use Monthly Pay Then apply 20% off Scenario: Jedi Master Plan with Annually Payment Given that the user does not reside in a country with a benefit When to enroll in the Jedi Master Plan and use Annually Payment Then apply 25% off
Have you notice how long it is, difficult to read, and looking for the correct business rule requires a lot of text to be read?
Could it be that part of the problem is due to the conversion of a rule written in natural language to a programming language, containing its paradigms, semantics and syntax?
How can we at least try to diminish this gap?
Decision Tables
Decision tables are a concise visual representation for specifying which actions to perform depending on given conditions. [Wikipedia]
The advantage of using decision tables is that they are very keyword-focused and ubiquitous, domain-oriented. In other words, we can consider it to be a tabular form of decision making.
The same rule written in natural language above was converted to a decision table, as follows:
Feature: Discount on subscribing to a plan on the platform
Condition | Monthly Padawan | Annually Padawan | Monthly Jedi Master | Annually Jedi Master | Country w/ Benefits |
Free Plan | | | | | |
Padawan Plan | ✓ | ✓ | | | |
Jedi Master Plan | | | ✓ | ✓ | |
Monthly payment | ✓ | | ✓ | | |
Annually Payment | | ✓ | | ✓ | |
Country w/ Benefits | | | | | ✓ |
Discount | 10% | 15% | 20% | 25% | 50% |
We converted about 24 lines of text into a 6x8 table. What do you think?
Show me the Code!

Going on with our example, there is a classic approach to code these decision-making structures, as follows:
decimal GetDiscount(Plan plan, User user, Payment payment)
{
if (CountryWithBenefit(user.Country))
return 50;
if (plan == plan.Padawan && payment == payment.Monthly)
return 10;
if (plan == plan.Padawan && payment == payment.Annually)
return 15;
if (plan == plan.JediMaster && payment == payment.Monthly)
return 20;
if (plan == plan.JediMaster && payment == payment.Annually)
return 25;
return 0;
}
Using C#8's Tuple Patterns we can reduce complexity and control flow:
decimal GetDiscout(Plan plan, User user, Payment payment) =>
(plan, payment, CountryWithBenefit(user.Country)) switch
{
(_, _, true) => 50,
(plan.Padawan, payment.Monthly, _) => 10,
(plan.Padawan, payment.Annually, _) => 15,
(plan.JediMaster, payment.Monthly, _) => 20,
(plan.JediMaster, payment.Annually, _) => 25,
(_, _, _) => 0
}
In terms of qualitative attributes, what did you think of readability?
How far are we from the tabular format for decision making?
This is just one more approach! If you have a different idea, please share! :)
Comments