Kogito DMN: Taking Business Rules Out of the Codebase

    Moving business rules out of code and into a governed, visible, CI-driven DMN decision layer.

    Published April 5, 2026

    Business logic accumulates inside the codebase.

    Not by negligence, but by momentum. A developer implements an eligibility check here, a scoring rule there, a ranking policy somewhere else. Each decision is reasonable in isolation. Collectively, they become a problem nobody planned for.

    The codebase becomes the only place where the actual behavior of the system is documented. Business stakeholders cannot read it. Product managers cannot verify it. And as teams change and velocity increases, even the engineers lose confidence in what the rules actually are. Someone asks why a candidate was ranked a certain way, and the honest answer is: you would need to trace through three services and a few hundred lines of logic to find out.

    That is not a technical debt problem. That is a governance problem. And it does not get better by itself. This project was about solving it properly.

    That is the problem this project was built to solve.

    Business logic

    The Solution

    Strip all business logic out of the application code and move it into a dedicated decision layer built on Kogito and DMN.

    DMN, Decision Model and Notation, is a standard for expressing business rules as structured decision tables. The rules are visual, readable, and editable without writing code. A business analyst can open a DMN table and immediately understand what inputs drive what outputs. They can propose a change, hand it to a DMN owner with technical background, and that owner raises a pull request with the updated file.

    From there, the process is automated.

    DMN Table

    The Architecture

    The system is organized across three layers: a product management layer where rules are authored and versioned, a CI/CD pipeline that validates and deploys changes, and a runtime decision service that exposes the rules as live API endpoints.

    Rule Authoring

    Business rules are maintained in two ways. A product manager can edit DMN tables directly using a visual Camunda Modeler. Changes are committed to a Git repository as versioned DMN files under src/main/resources/decisions/.

    CI/CD Pipeline

    Every pull request triggers a validation and deployment pipeline.

    The first stage parses the DMN XML, checks element types, validates rule IDs against defined standards, checks stage vocabulary, and extracts metadata. Invalid files fail the build before anything is deployed.

    If validation passes, the pipeline runs in parallel: the registry is auto-generated from the DMN files, the Kogito decision service is built and compiled, and the NestJS microservices are bundled with the decision client. On success, all services are deployed and documentation is published automatically.

    Runtime Decision Service

    The Kogito service runs as a cloud-native microservice. It loads DMN files directly from the repository and exposes auto-generated REST endpoints for each decision: candidate visibility, ranking weights, and reset policy. Each call returns a full execution trace, the fired rules, matched rule IDs, and the evaluated conditions. Full FEEL 1.3 compliance, hot reload capable.

    The Integration

    The decision layer was integrated into existing NestJS microservices, each extended to call the Kogito decision API as part of its request flow.

    The integration used shadow mode. The existing logic continued serving responses as normal while every request was simultaneously routed to the new decision service. Both results were compared and differences logged, validating the new layer against real production traffic before any cutover.

    Observability

    All decision calls, execution traces, shadow mode comparisons, and difference logs are written to BigQuery. A dashboard surfaces rule firing frequency, decision metrics, and shadow mode diff counts. A what-if simulator allows replaying requests against the Kogito API to test rule changes and predict impact before deploying them.

    The Result

    Business stakeholders can now open a DMN table and see exactly what rules are running. They can propose changes through a governed process without touching application code. Every change is version controlled, validated by CI, tested against defined input/output pairs using Kogito's native testing capabilities, and deployed automatically on merge.

    Developers no longer own the business rules. The business does. And both sides can see exactly what the system is doing.

    dmnkogitodecisionbpmncicdapachekie

    Open calendar

    Building or maintaining a workflow system?

    If you’re dealing with workflow architecture, BPMN tooling, automation design, or the realities of running process systems in production, I help teams think through the hard parts clearly.

    No pitch. Just a direct technical conversation.

    Let's talk