AutoflowTrilha 03 · DMN e regras de negócio
Por que separar regras do fluxo
Todo processo tem decisões. Quando a lógica dessas decisões fica escondida dentro do desenho, cada mudança de política vira uma nova versão do fluxo. O DMN tira as regras do desenho e as coloca numa tabela que o próprio gestor consegue ler.
Fluxo e decisão são coisas diferentes
Imagine o processo de compras de uma prefeitura. O fluxo responde “o que acontece depois do quê”: alguém pede, alguém analisa, alguém cota, alguém empenha. A decisão responde a outra pergunta: “neste caso específico, quem precisa aprovar?”. A resposta depende de valor, modalidade de licitação, secretaria e às vezes de um decreto publicado no mês passado.
Se você desenhar essa decisão com gateways, o diagrama fica assim: um losango “valor acima de 17 mil?”, outro “é obra?”, outro “é emergencial?”, com caminhos se cruzando. Funciona — até o decreto mudar o limite. Aí você precisa abrir o editor, achar o gateway certo, alterar a condição ${valor > 17600} e publicar uma nova versão do fluxo.
O DMNDMN — Decision Model and Notation — padrão para modelar decisões de negócio em tabelas legíveis, separadas do fluxo. (Decision Model and Notation) é o padrão irmão do BPMN, mantido pela mesma organização (OMG), feito exatamente para separar essas duas coisas. O fluxo continua dizendo a ordem das etapas; a decisão vira uma tabela de decisãoTabela de decisão — Tabela onde cada linha é uma regra: se as entradas casam, as saídas são devolvidas. que o fluxo consulta.
Regras de negócio mudam muito mais rápido que processos. Uma alçada de desconto pode mudar todo trimestre; o processo de venda pode ficar anos igual. Separar os dois permite mudar a regra sem mexer no fluxo e permite que quem entende da regra (o gerente, o jurídico, o controle interno) leia e valide a tabela sem saber BPMN.
Como uma tabela de decisão funciona
Uma tabela de decisão tem colunas de entrada (o que a regra lê), colunas de saída (o que a regra devolve) e linhas. Cada linha é uma regra completa: “se as entradas forem assim, a saída é esta”.
| Percentual de desconto (entrada) | Precisa aprovação? (saída) | Aprovador (saída) |
|---|---|---|
> 15 |
true |
"GROUP_ADMIN" |
> 5 |
true |
"MATRIX_MANAGER" |
- |
false |
"SALES_CONSULTANT" |
Leitura em português: “se o desconto passa de 15%, quem aprova é o administrador do grupo; se passa de 5%, o gerente da matriz; senão, o próprio consultor”. O traço - significa “qualquer valor”.
Essa é uma regra real do pacote Concessionária do Autoflow (alcadaDesconto). Experimente: mude o percentual e veja qual linha casa.
O que o processo faz com o resultado
A tabela sozinha não faz nada. Ela é chamada por um elemento do fluxo — a tarefa de regra de negócio (no Autoflow, o bloco Regra de negócio). O fluxo envia as entradas (que vieram de formulários anteriores), recebe as saídas e as guarda como variáveisVariável de processo — Dado guardado na instância (ex.: valor, tipoVenda). Vem dos campos dos formulários e das regras; usado nas condições dos gateways.. Daí em diante, um gateway pode testar a saída, uma tarefa pode usar a saída como responsável, uma solicitação de documentos pode usar a saída como lista de itens.
Clique nos elementos do diagrama abaixo para ver o papel de cada um:
Se você se pegar desenhando três ou mais gateways seguidos testando a mesma família de dados (valor, tipo, categoria), pare. Isso é uma decisão pedindo para virar tabela.
Benefícios concretos
Muda a regra, não o fluxo
No Autoflow, a versão publicada de uma regra vale na próxima avaliação de todos os processos — inclusive dos que já estão em andamento. Sem republicar o fluxo.
O gestor lê a tabela
Uma tabela com três linhas é auditável por qualquer pessoa. Um emaranhado de gateways não é.
Fica registrado o porquê
A linha do tempo do processo mostra “Regra X vN · entradas → saídas (linha N)”. Dá para provar por que aquele caso foi para o comitê.
Testável isoladamente
Você testa a tabela com vários casos antes de publicar, sem precisar rodar o processo inteiro.
No setor público, a rastreabilidade da decisão é um requisito, não um luxo. Princípios como motivação dos atos administrativos e transparência pedem que se possa explicar por que um requerimento foi priorizado ou encaminhado a determinada instância. Uma decisão registrada com “regra, versão, entradas e linha que casou” é uma evidência objetiva. Anote a base legal na descrição de cada linha (por exemplo, “Estatuto da Pessoa Idosa, art. 3º”).
Onde ficam as regras no Autoflow
As regras moram em Administração › Modelagem › Regras. Quem cria, edita e testa precisa da permissão Modelar processo (process.model); quem publica, arquiva e exclui precisa de Publicar processo (process.publish). A tela explica: “Tabelas de decisão usadas pelo bloco Regra de negócio. A versão publicada vale na próxima avaliação de todos os processos.”
O editor de regras do Autoflow é próprio (não é o editor DMN genérico do mercado) e foi simplificado de propósito:
- uma tabela de decisão por regra (sem diagramas de requisitos de decisão, os DRDs);
- três políticas de “quando mais de uma linha casa” (veja a lição Hit policies);
- tipos de dados pensados para processos: Texto, Número, Data, Cargo, Unidade e Documento.
Por baixo, ele grava um arquivo DMN 1.3 padrão, que o motor Camunda executa.
Quando a plataforma cria uma organização com segmento Concessionária, ela já recebe as regras alcadaDesconto e docsPorTipoDeVenda. Com segmento Advocacia, recebe prazoPorAto e honorariosPorAcao. Elas aparecem com a tag “Pacote do segmento” e servem como ponto de partida — e como ótimo material de estudo.
Como levantar regras com o cliente
Regras de negócio raramente estão escritas. Elas vivem na cabeça de quem executa: “ah, mas quando é pessoa jurídica a gente pede o contrato social também”. Na entrevista de descoberta, caçe frases com este formato:
- “Quando … então …”
- “Depende de …”
- “Se for acima de / abaixo de …”
- “Nesse caso quem aprova é …”
- “Para pessoa física é um prazo, para jurídica é outro”
Cada frase dessas é uma linha de tabela. Anote numa planilha com colunas de entrada e saída já na reunião; o cliente entende uma tabela muito mais rápido do que entende um diagrama.
- Descubra a pergunta. Toda tabela responde a uma pergunta: “quem aprova?”, “qual o prazo?”, “quais documentos?”. Dê a ela esse nome.
- Liste as entradas. O que a pessoa olha para decidir? Valor, tipo, idade, área. Confira se esses dados já existem em algum formulário do processo.
- Liste as saídas. O que a decisão produz? Um cargo, um número de dias, um sim/não, uma lista de documentos.
- Preencha as linhas com exemplos reais e casos de borda (exatamente 5%? exatamente 60 anos?).
- Feche com uma linha “senão”, com todas as entradas
-, para nunca ficar sem resposta. - Valide com o dono da regra lendo linha a linha em voz alta.
Resumo
- BPMN descreve a ordem das etapas; DMN descreve como uma decisão é tomada.
- Uma tabela de decisão tem entradas, saídas e linhas; cada linha é uma regra.
- O fluxo chama a tabela pela tarefa de regra de negócio e recebe as saídas como variáveis.
- No Autoflow, regras ficam em Modelagem › Regras e a versão publicada vale imediatamente para todos os processos.
- Separar regra de fluxo reduz versões do processo, aumenta transparência e deixa a decisão auditável.