Drools Tutorial Series Part 3: Decision Tables & DMN

In Part 3 of our Drools tutorial series, we take a look at decision tables, DMN, and practical patterns for modeling business logic for clarity and reuse.

Decision tables and DMN are two practical ways to represent business logic so it is understandable by both engineers and domain experts. They reduce hidden logic and make rules easier to test and reuse.

In this part of the series, we are going to dive in to decision tables and DMN: when to use them, and how they work, with a concrete shipping-cost example.

Decision table vs. DRL: choose the right tool

Decision tables excel when logic maps cleanly to a matrix of conditions and outputs — pricing bands, fee tables, or eligibility matrices. DRL is better for procedural or complex conditional logic.

Use decision tables for clarity; use DRL for orchestrating multiple tables or performing complex computations.

Shipping-cost example (concise)

Problem: determine shipping price based on weight, distance, and service level.

A simple CSV decision table might look like:

MinWeight,MaxWeight,DistanceBand,Service,Price
0,1,0-50,standard,5.00
0,1,0-50,express,8.00
1.01,5,50-200,standard,12.00
1.01,5,50-200,express,18.00
...

In Drools you can convert Excel or CSV decision tables into rule assets and load them into a KIE module. The engine evaluates the table rows as rules and returns the matched price.

DMN for composed decisions

DMN is useful when decisions depend on other decisions (decision requirement diagrams). For example, calculate a base price via a decision table and then apply discounts or surcharges via another decision node.

Drools provides DMN support so you can evaluate DMN models at runtime and combine them with DRL when needed.

Testing and versioning tables

Treat decision tables like code: keep them in version control, and add tests that exercise representative rows. Use parametrized tests that iterate over CSV examples and assert expected outcomes.

Exposing tables to SMEs

Provide a simple editor (Excel, web table UI, or a DMN editor) and a guarded workflow for applying changes. For low-risk edits, consider letting SMEs update tables in a staging environment subject to test runs and QA signoff.

Example: loading a decision table in Drools (concept)

• Author the table in Excel and save as .xls or .xlsx
• Add the table to the KIE project under src/main/resources
• Configure the kmodule.xml and build the KJAR
• At runtime, call the KIE session that evaluates the decision table row(s)

Best practices

• Normalize input values (e.g., distance bands) so tables remain compact
• Prefer ranges and enums rather than many single-value rows
• Add human-readable descriptions for rows to aid SME review
• Use small tables focused on single concerns; compose multiple tables when needed

[Placeholder graphic: decision table Excel snippet and a DMN DRD showing dependencies]

Conclusion

Decision tables and DMN shift rule creation closer to the domain experts and make logic easier to test and audit. Use them for pricing, eligibility, and similar matrix-like logic, and combine them with DRL for orchestration and complex processing.

Be sure to subscribe to get notified of future guides like this, and of course Be sure to subscribe to get notified of future guides.

Learn more

Explore our Fusion Platform our Fusion Platform which offers visual builders for decision tables, DMN, and workflows that can deploy as secure, scalable APIs in minutes.