DMN na prática: tornar regras de negócio visíveis e testáveis
Problema clássico: políticas de negócio espalhadas por “ifs” e switches no código. Cada alteração regulatória implica um sprint de desenvolvimento, regressões imprevisíveis e pouca transparência para auditoria.
Solução: DMN (Decision Model and Notation) — um padrão aberto para modelar, executar e governar decisões de negócio de forma independente do código de aplicação, tornando-as visíveis, versionadas e testáveis.
O que é DMN (e o que não é)
DMN é um standard que descreve como representar e avaliar decisões. Complementa BPMN (fluxos) e CMMN (casos): enquanto BPMN define quando tomar uma decisão, DMN define como a decisão é tomada. DMN não é apenas “tabela de decisão”; inclui vários artefactos:
- DRD (Decision Requirements Diagram): diagrama que mostra decisões, entradas de dados, Business Knowledge Models (BKM) e dependências.
- Tabelas de decisão: matriz de condições (entradas) vs. ações (saídas), com hit policies (FIRST, UNIQUE, ANY, PRIORITY, etc.).
- Boxed expressions: formas estruturadas de lógica (tabela, expressão literal, contexto, invocação, lista, relation, BKM).
- FEEL (Friendly Enough Expression Language): linguagem declarativa usada nas condições e expressões.
Porque interessa: separa a política (decisão) do processo (sequência) e do código (implementação técnica), reduzindo acoplamento e acelerando mudanças.
Para que serve DMN
- Transparência para negócio e IT: regras legíveis, com termos do domínio.
- Mudança rápida: alterar políticas sem recompilar a aplicação.
- Testabilidade: simulação e testes automatizados antes do deploy.
- Reutilização: a mesma decisão serve vários processos/serviços.
- Auditoria & conformidade: trilho de decisões claro (inputs/outputs).
Quando usar: scoring, elegibilidade, roteamento, precificação, validações, risk-based approach, cálculo de prazos, priorização. Quando não usar: lógica algorítmica pesada/iterativa (melhor noutro serviço) ou regras que mudam por sprint e exigem otimização de baixo nível.
Conceitos essenciais em 5 minutos
- Entradas/saídas bem definidas: nomeia e tipa os dados (string, number, boolean, date, etc.).
- Hit policy: define como resolver múltiplas regras que “disparam” (FIRST, UNIQUE, ANY, COLLECT…).
- FEEL: condições expressivas (ex.:
>= 680,"LOW",between 640 and 699). - DRD modular: parte decisões grandes em sub-decisões reutilizáveis.
- Decision service: encapsula e expõe decisões a processos e APIs.
Exemplo DMN 1.3 (importável no Modeler)
Decisão “STPEligibility” com hit policy FIRST. Entradas: riskTier, score, pepMatch, docsComplete. Saída: result (STP/REVIEW). XML compatível com DMN 1.3.
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="https://www.omg.org/spec/DMN/20191111/MODEL/"
xmlns:feel="https://www.omg.org/spec/DMN/20191111/FEEL/"
id="defs" name="STPDefinitions" namespace="http://example.tld/dmn">
<decision id="STPEligibility" name="STPEligibility">
<decisionTable id="table" hitPolicy="FIRST">
<input id="i1">
<inputExpression id="iex1" typeRef="string"><text>riskTier</text></inputExpression>
</input>
<input id="i2">
<inputExpression id="iex2" typeRef="number"><text>score</text></inputExpression>
</input>
<input id="i3">
<inputExpression id="iex3" typeRef="boolean"><text>pepMatch</text></inputExpression>
</input>
<input id="i4">
<inputExpression id="iex4" typeRef="boolean"><text>docsComplete</text></inputExpression>
</input>
<output id="o1" name="result" typeRef="string"/>
<rule id="r1">
<inputEntry id="ie11"><text>-</text></inputEntry>
<inputEntry id="ie12"><text>-</text></inputEntry>
<inputEntry id="ie13"><text>true</text></inputEntry>
<inputEntry id="ie14"><text>-</text></inputEntry>
<outputEntry id="oe1"><text>"REVIEW"</text></outputEntry>
</rule>
<rule id="r2">
<inputEntry id="ie21"><text>-</text></inputEntry>
<inputEntry id="ie22"><text>-</text></inputEntry>
<inputEntry id="ie23"><text>-</text></inputEntry>
<inputEntry id="ie24"><text>false</text></inputEntry>
<outputEntry id="oe2"><text>"REVIEW"</text></outputEntry>
</rule>
<rule id="r3">
<inputEntry id="ie31"><text>"LOW"</text></inputEntry>
<inputEntry id="ie32"><text>>= 640</text></inputEntry>
<inputEntry id="ie33"><text>false</text></inputEntry>
<inputEntry id="ie34"><text>true</text></inputEntry>
<outputEntry id="oe3"><text>"STP"</text></outputEntry>
</rule>
<rule id="r4">
<inputEntry id="ie41"><text>"MEDIUM"</text></inputEntry>
<inputEntry id="ie42"><text>>= 680</text></inputEntry>
<inputEntry id="ie43"><text>false</text></inputEntry>
<inputEntry id="ie44"><text>true</text></inputEntry>
<outputEntry id="oe4"><text>"STP"</text></outputEntry>
</rule>
<rule id="r5">
<inputEntry id="ie51"><text>"HIGH"</text></inputEntry>
<inputEntry id="ie52"><text>-</text></inputEntry>
<inputEntry id="ie53"><text>-</text></inputEntry>
<inputEntry id="ie54"><text>-</text></inputEntry>
<outputEntry id="oe5"><text>"REVIEW"</text></outputEntry>
</rule>
</decisionTable>
</decision>
</definitions>
Invocar DMN a partir de BPMN
Num processo (Camunda 8.x), usa um Business Rule Task com zeebe:calledDecision e mapeia o resultado para uma variável:
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:zeebe="http://camunda.org/schema/zeebe/1.0"
targetNamespace="http://example.tld/bpmn">
<process id="stp_process" name="STP Process" isExecutable="true">
<startEvent id="start"/>
<sequenceFlow id="f1" sourceRef="start" targetRef="evaluateDecision"/>
<businessRuleTask id="evaluateDecision" name="Evaluate STP">
<extensionElements>
<zeebe:calledDecision decisionId="STPEligibility"/>
<zeebe:resultVariable name="stpResult"/>
</extensionElements>
</businessRuleTask>
<sequenceFlow id="f2" sourceRef="evaluateDecision" targetRef="end"/>
<endEvent id="end"/>
</process>
</definitions>
Dica: mantém os inputs esperados pela decisão como variáveis do processo (ex.: riskTier, score…). Podes usar input mappings se precisares de transformação.
Testes e simulação (antes do deploy)
Define test vectors para validar as regras. Exemplo:
[
{ "name": "LOW+660 sem PEP, docs OK → STP",
"input": { "riskTier": "LOW", "score": 660, "pepMatch": false, "docsComplete": true },
"expect": { "result": "STP" } },
{ "name": "MEDIUM+700 sem PEP, docs OK → STP",
"input": { "riskTier": "MEDIUM", "score": 700, "pepMatch": false, "docsComplete": true },
"expect": { "result": "STP" } },
{ "name": "PEP true → REVIEW",
"input": { "riskTier": "LOW", "score": 790, "pepMatch": true, "docsComplete": true },
"expect": { "result": "REVIEW" } },
{ "name": "Docs incompletos → REVIEW",
"input": { "riskTier": "LOW", "score": 800, "pepMatch": false, "docsComplete": false },
"expect": { "result": "REVIEW" } }
]
Executa estes testes no teu pipeline CI/CD. Cada alteração às regras é validada automaticamente, reduzindo regressões e encurtando o ciclo de mudança.
Boas práticas de modelação DMN
- Vocabulário do domínio: usa nomes claros (ex.:
riskTierem vez dert). - Modulariza via DRD: divide decisões extensas em sub-decisões (ex.: DocumentsOK, RiskScore, STPEligibility).
- Escolhe a hit policy certa: FIRST para primeira correspondência; UNIQUE se as regras forem mutuamente exclusivas; COLLECT quando precisas de somar/concatenar.
- Boxed expressions quando a tabela não chega: usa “Context”, “Literal Expression”, “Invocation”, etc.
- Versionamento: versiona decisões como artefactos (semântico + técnico) e documenta mudanças.
- Observabilidade: regista inputs/outputs (com privacidade) para auditoria e troubleshooting.
Armadilhas a evitar
- Tabelas gigantes sem normalização: preferir sub-decisões e BKMs reutilizáveis.
- Regras implícitas (“às vezes”): torna as condições explícitas em FEEL.
- Falta de dono: define um decision product owner e um fluxo de aprovação.
- Acoplamento ao processo: não mistures regras complexas dentro do BPMN; invoca DMN.
Como DMN se relaciona com BPMN e CMMN
- BPMN: gere o quando (sequência, eventos, SLAs). Invoca DMN em pontos de decisão.
- DMN: gere o como (política de decisão). Fornece resultados ao fluxo.
- CMMN: gere o caso (trabalho não estruturado, exceções). Pode consultar DMN para triagem/roteamento.
Resultado
Com DMN, as regras de negócio tornam-se claras, auditáveis e fáceis de manter. O negócio ganha autonomia para evoluir políticas; IT ganha estabilidade e testes; compliance ganha visibilidade. Menos “ifs” escondidos, mais decisões governadas — e processos que evoluem ao ritmo do negócio.
You may also like
Leave a Reply