Decision Model and Notation (DMN): A Comprehensive Introduction

Introduction to DMN

Origins and Evolution

Decision Model and Notation (DMN) emerged in the mid-2010s as a response to the need for a standardized way to model business decisions. Unlike previous decision management approaches that were vendor-specific, DMN was designed from the ground up as an open standard administered by the Object Management Group (OMG), the same organization responsible for other widely-adopted standards like BPMN and UML.

DMN provides both a visual modeling notation and an execution framework, making it uniquely powerful compared to other standards like BPMN, which primarily focuses on process modeling rather than execution semantics. This dual nature of DMN enables true vendor neutrality - models created in one tool can be executed in any DMN-compliant engine without modification.

What Makes DMN Special?

DMN stands for "Decision Model and Notation" and represents a significant advancement in business automation technologies. Unlike traditional business rule approaches, DMN offers:

• Standard Notation: A unified graphical representation that business analysts and technical teams both understand

• Direct Execution: Models created by business users can be executed without translation to code

• Declarative Approach: Focusing on what decisions should be made rather than how

• Separation of Concerns: Clear distinction between decision requirements and decision logic

• Friendly Expression Language: FEEL (Friendly Enough Expression Language) offers precise expressions without requiring programming knowledge

At Aletyx, we believe DMN represents the future of decision management - a truly vendor-agnostic standard that empowers organizations to own their decision logic rather than being locked into proprietary systems.

Core DMN Concepts

Decision Requirements Diagram (DRD)

The Decision Requirements Diagram (DRD) represents the high-level view of a decision model, showing:

• Decisions: Represented as rectangles that determine output values using defined logic
• Input Data: Ovals that represent external information provided to the decision model
• Knowledge Sources: Shapes that identify the source of the decision logic (e.g., policy documents, regulations)
• Knowledge Models: Reusable decision logic components that can be shared across decisions
• Dependencies: Arrows showing information requirements between elements

DRDs provide a clear visual representation of decision dependencies, making complex decision structures easier to understand and communicate across teams.

Decision Tables

One of the most powerful aspects of DMN is the decision table - a tabular representation of conditions and conclusions. Key elements include:

• Hit Policy: Defines how to handle multiple matching rules (Unique, First, Priority, etc.)

• Input Expressions: The conditions to evaluate

• Output Expressions: The values to return when conditions are met

• Annotations: Optional comments explaining the business rationale for rules

Decision tables excel at representing complex conditional logic in a format that's easily understood by business stakeholders while remaining precise enough for execution.

Example Decision Table: Travel Risk Assessment

U	Destination Region	Risk Level	Annotations
1	"North America"	"Low"	Stable region with good infrastructure
2	"Western Europe"	"Low"	Established travel infrastructure
3	"Southeast Asia"	"Medium"	Variable infrastructure by country
4	"Middle East"	"High"	Political instability in some areas
5	-	"Medium"	Default for unspecified regions

FEEL (Friendly Enough Expression Language)

FEEL is the expression language defined by the DMN standard for writing decision logic. Key characteristics include:

• Business-friendly syntax: Designed to be readable by non-programmers

• Type system: Includes numbers, strings, booleans, dates, time, and complex structures

• Function library: Built-in functions for common operations

• Range expressions: Easy specification of value ranges (e.g., [5..10])

• List operations: Working with collections of values

• Context expressions: Creating named groups of values

FEEL supports everything from simple expressions to complex decision logic while remaining accessible to business users.

Hit Policies

Hit policies define how a decision table handles situations where multiple rules could match the input data:

• Unique (U): One and only one rule can match (enforced by the engine)

• First (F): Only the first matching rule is applied (based on rule order - the higher in the table rule will be the one that fires)

• Priority (P): Highest priority output is selected

• Any (A): Any matching rule can be applied (but all must have the same output)

• Collect (C): All matching rules are applied and outputs collected (with optional aggregation)

• Rule Order (R): All matching rules are applied in order

• Output Order (O): All matching rule outputs are ordered

Choosing the appropriate hit policy is crucial for ensuring decision tables behave as intended.

Advanced DMN Concepts

Boxed Expressions

Beyond decision tables, DMN supports other types of boxed expressions:

• Literal Expressions: Simple values or formulas - age >18

• Context Expressions: Sets of name-value pairs - can create more complex decisions through filtering and other methods

• Function Definitions: Reusable logic with parameters

• Invocations: Calls to defined functions

• Lists: Collections of values

• Relations: Tabular data structures

These expression types provide powerful capabilities for implementing complex decision logic.

Business Knowledge Models (BKMs)

Business Knowledge Models encapsulate reusable decision logic that can be referenced by multiple decisions. They:

• Promote reusability across decision models
• Enable modular design of complex decisions
• Support versioning of decision components
• Facilitate testing of decision logic in isolation

BKMs are particularly valuable for organizations with common decision patterns that need to be applied consistently.

Practical DMN Implementation

Getting Started with Aletyx Playground

The Aletyx Playground provides an accessible environment for creating and testing DMN models. Here's how to create your first model:

1. Navigate to Aletyx Playground
2. Select "New Decision" to create a DMN model
3. Define your input data nodes (ovals)
4. Create decision nodes (rectangles)
5. Connect them with information requirement arrows
6. Define the decision logic for each node

The Aletyx Playground allows real-time testing of your model, providing immediate feedback as you develop when using the Extended Services.

Real-World Example: Vacation Days Calculation

Let's examine a practical example of a DMN model for calculating vacation days:

Input Data

• Age: The employee's age (number)

• Years of Service: Years the employee has worked (number)

Decision Structure:

• Base Vacation Days: A literal expression defining the standard vacation allocation (22 days)

• Extra Days Case-1: Additional days based on age extremes or long service

• Extra Days Case-2: Additional days based on age and service combinations

• Extra Days Case-3: Additional days for moderate service or middle age

• Total Vacation Days: The final decision combining all components

Decision Tables Example

For Extra Days Case-1:

Hit Policy: Collect Max

Age	Years of Service	Extra Days Case-1	Annotation
<18, >=60	-	5	// Less than 18 or older than 60
-	>30	7	// More than 30 years of service
-	-	0	// Default - no extra days

For the Total Vacation Days decision, we can use a literal expression:

Base Vacation Days + max(Extra days case-1, Extra days case-3) + Extra days case-2

This example demonstrates the modularity of DMN, breaking a complex decision into manageable components that can be independently designed, tested, and maintained. To go further into this example, see the DMN Basic Example

Integration Patterns

DMN and BPMN Integration

DMN models can be seamlessly integrated with BPMN processes using business rule tasks:

1. The BPMN process encounters a decision point
2. A business rule task invokes the DMN model
3. The DMN model evaluates inputs and returns a decision
4. The process continues based on the decision result

This pattern ensures that process flow and decision logic remain separate concerns, allowing each to be changed independently.

Event-Driven Decision Services

DMN models can also be deployed as standalone decision services in event-driven architectures:

1. Events trigger the decision service
2. The service evaluates the decision model
3. Decision results trigger subsequent actions
4. The entire flow operates in a reactive, scalable manner

This pattern is particularly effective for high-volume, low-latency decision scenarios.

Advanced Techniques

Working with Collections

DMN provides powerful capabilities for working with collections of values:

some item in collection satisfies condition
every item in collection satisfies condition
collection[condition]
count(collection)
sum(collection)

These operators enable complex filtering and aggregation operations within decision models.

Context Expressions

Context expressions allow the creation of intermediate values during decision evaluation:

{
  "temporary value": some calculation,
  "another value": more logic,
  result: final calculation using the above values
}

Contexts are particularly useful for breaking down complex calculations into manageable steps.

Best Practices

Modeling Approaches

When creating DMN models, consider these approaches:

1. Top-down: Start with high-level decisions and decompose into sub-decisions
2. Bottom-up: Identify basic decisions and combine into more complex ones
3. Middle-out: Begin with the most important decisions and work outward

Each approach has advantages depending on your specific decision modeling scenario.

Testing Strategies

Effective DMN testing includes:

1. Unit testing individual decision components
2. Integration testing of the complete decision model
3. Scenario testing with business-defined test cases
4. Performance testing under expected load conditions

The declarative nature of DMN makes it particularly amenable to automated testing.

DMN and Modern Architecture

Cloud-Native Deployment

DMN models can be deployed in modern cloud architectures:

1. Containerized Deployments: Packaged as lightweight containers
2. Serverless Functions: Deployed as on-demand decision services
3. Microservice Architecture: Integrated within microservice ecosystems
4. Event-Driven Processing: Connecting to event streams and message brokers

These deployment patterns ensure DMN models can operate at scale in modern application landscapes.

DevOps and CI/CD

DMN models benefit from modern development practices:

1. Version Control: Managing decision model changes
2. Continuous Integration: Automated testing of decision logic
3. Continuous Deployment: Streamlined deployment to production
4. Monitoring and Observability: Runtime decision analytics

By treating decision models as first-class development artifacts, organizations can ensure consistent, high-quality decision automation.

Summary

Decision Model and Notation (DMN) represents a paradigm shift in how organizations approach decision management. By providing a standard that combines business-friendly representation with executable precision, DMN bridges the gap between business and IT, enabling truly collaborative decision automation.

At Aletyx, we're committed to advancing the state of the art in DMN implementation, building on the solid foundation of the Apache KIE ecosystem while extending it with enterprise-grade capabilities. Our documentation, tools, and support are designed to make DMN accessible to organizations at any stage of their decision management journey.

Was this page helpful?