Como identificar regras de negócio embutidas no código, classificar candidatas à externalização e fazer a transição sem travar o time de engenharia.
Regras de negócio
# Externalização de regras de negócio: o guia do gerente de engenharia de seguros
Pega o último sprint do seu time. Conta quantos tickets são, na prática, mudança de critério de negócio disfarçada de desenvolvimento. Taxa de sinistro ajustada. Fator regional atualizado. Alíquota que mudou por portaria. Cobertura que a área comercial prometeu ontem e precisa estar em produção na segunda-feira.
Em times de engenharia de seguradoras com esse perfil, 35% a 45% do backlog técnico são tickets assim. Não são bugs. Não são features. São regras de negócio que moram no código e que precisam de engenheiro para se mover.
O problema não está no analista que abriu o ticket, nem no gerente que priorizou. Está na arquitetura. E esse texto é sobre como identificar onde a arquitetura está errando, como modelar a saída, e como fazer a transição sem travar o time que já está no limite.
Todo engenheiro de seguradoras já encontrou esse módulo. Não tem dono claro. A documentação está desatualizada. Quem escreveu saiu há dois anos. O código mistura lógica de domínio com lógica de infraestrutura, e os comentários são do tipo "// não mexa aqui sem falar com o Rafael" — o Rafael que saiu em 2023.
Esse módulo existe porque, em algum ponto da história do produto, alguém precisava decidir qual regra aplicar e a solução mais rápida foi um if-else. Depois virou if-else-if. Depois virou uma classe de 800 linhas que calcula prêmio comercial misturando fatores de risco, tabelas de franquia, lógica de desconto por canal e condições de vigência: tudo no mesmo lugar, tudo acoplado, nada testável isoladamente.
Refatorar esse módulo é um projeto de duas semanas que ninguém consegue justificar no roadmap porque "funciona". O problema é que "funciona" significa que qualquer mudança de regra custa 2 engenheiros por 2 dias, mais QA, mais deploy, mais o risco de quebrar algo que estava funcionando nas sombras.
O custo médio de um ticket de regra urgente, considerando hora de engenheiro, interrupção de sprint e custo de oportunidade da feature que ficou parada, fica entre R$ 8.000 e R$ 15.000 dependendo do tamanho e maturidade do time. Multiplica por 30 tickets mensais e estamos falando de um problema de capital, não de produtividade.
A primeira pergunta que um arquiteto de software deveria fazer antes de qualquer ticket de regra é: essa lógica precisa de engenheiro para mudar, ou está no código por inércia?
Há critérios objetivos para identificar regras candidatas. Regras que mudam com frequência maior que o ciclo de release do produto são candidatas imediatas. Regras que dependem de decisão do negócio (não de dado técnico) são candidatas diretas. Regras que precisam de versionamento com data de vigência, como tabelas de tarifas com efeito retroativo ou faixas de prêmio com início e fim determinados, são candidatas críticas.
No contexto de seguros, essas categorias se repetem com frequência em implementações que acompanhamos:
Critérios de subscrição: regras que definem aceitação de risco, limites de exposição por perfil, exclusões por característica do bem ou do segurado. Mudam quando o atuário revisa a política de risco, quando o ressegurador atualiza as condições, ou quando a sinistralidade de um ramo sobe além do threshold definido.
Tabelas de tarifas e fatores de risco: fator regional, fator por tipo de construção, agravamento por histórico de sinistros, desconto por múltiplos produtos. São variáveis que a área atuarial precisa ajustar com base em dados de frequência e severidade, e que hoje geram ticket para TI em vez de ajuste direto pelo responsável técnico.
Regras de elegibilidade de cobertura: condições para aplicar ou excluir uma cobertura específica, validações de combinação de franquia e soma segurada, regras de endosso. Essas regras mudam quando o produto muda, quando a regulação muda, ou quando a área comercial lança uma variação para um canal específico.
Critérios de cálculo de prêmio: fórmulas de prêmio puro, carregamento comercial, IOF, cálculo pro rata por vigência. Quando a nota técnica atuarial é atualizada, a fórmula precisa mudar na mesma data de vigência da nota, com rastreabilidade de quem autorizou e qual versão foi aplicada a cada apólice.
Se uma regra se encaixa em qualquer dessas categorias, ela tem custo arquitetural visível quando fica no código e custo regulatório quando não é versionada.
DMN (Decision Model and Notation) é um padrão da OMG para modelar decisões de forma estruturada, legível por humanos e executável por máquina. A sintaxe principal é a tabela de decisão: um conjunto de condições de entrada, regras mapeadas linha a linha, e uma saída determinística para cada combinação.
O que DMN resolve bem: decisões com múltiplas variáveis de entrada e saída determinística. O cálculo de agravamento por CEP, faixa de valor do bem e tipo de construção resulta em um fator que alimenta a fórmula de prêmio. Isso é uma tabela de decisão. Quatro colunas, 40 linhas, e o analista de negócio consegue ler, validar e alterar sem precisar abrir o repositório.
O que DMN não resolve: lógica que exige processamento stateful, integração com sistemas externos em tempo real, ou decisões que dependem de inferência sobre dados não-estruturados. Para isso, outras abordagens são mais adequadas. DMN foi feito para decisão determinística, auditável e governada pelo negócio. Dentro desse escopo, ele é preciso.
A diferença prática é concreta: uma alteração em uma tabela de decisão DMN, feita diretamente pelo analista de negócio em um motor de regras externalizado, leva em média 20 minutos desde a identificação da necessidade até a versão publicada com vigência definida. O mesmo ajuste via ciclo de desenvolvimento convencional, contando spec, desenvolvimento, QA, aprovação e deploy, leva de 3 a 5 dias úteis. Esse delta é o custo de oportunidade de cada sprint gasto com mudança de regra em vez de construção de produto.
A armadilha mais comum ao externalizar regras de negócio é tratar o projeto como uma migração completa. Mapeia-se tudo, modela-se tudo, planeja-se um corte único, e seis meses depois o projeto está parado por causa de uma regra de cálculo que ninguém conseguia especificar completamente, enquanto o backlog de features continua crescendo.
A abordagem que funciona começa por um módulo específico, de alto impacto em termos de frequência de mudança e baixo risco em termos de dependências. A ideia é validar o ciclo completo, de modelagem em DMN até deploy e monitoramento em produção, antes de comprometer o time com escopo maior.
Para escolher o módulo piloto, o critério mais útil é frequência de tickets nos últimos 90 dias, cruzada com complexidade técnica. Um módulo de cálculo de fator de risco que gerou 12 tickets no trimestre, com mudanças relativamente simples de tabela, é candidato ideal. Um módulo de cálculo de prêmio que mistura três subsistemas e tem dependências não documentadas com o sistema de emissão fica para uma fase posterior.
O diagnóstico de dependências precisa acontecer antes da modelagem. Qual serviço consome esse cálculo? Existe cache de resultado que precisa ser invalidado? Há alguma lógica de compensação que depende do valor retornado? Essas perguntas parecem óbvias, mas em implementações que acompanhamos, o descobrimento de uma dependência não documentada no meio da migração é o principal motivo de atraso. Às vezes é uma dependência com o sistema de emissão que ninguém havia registrado, encontrada só no momento da integração em homologação.
O processo de modelagem começa com a extração da lógica existente. Isso geralmente envolve leitura de código com o desenvolvedor que tem mais contexto daquele módulo, validação com o analista de negócio que conhece a intenção da regra, e produção de um documento intermediário que registra as condições de entrada, os critérios de decisão e as saídas esperadas.
Em seguros, esse processo frequentemente revela inconsistências que já existem no código. Regras que foram atualizadas parcialmente e têm comportamentos diferentes dependendo do caminho de execução. Condições de borda que ninguém lembra como chegaram lá. Fatores de risco ajustados via hotfix há dois anos, sem documentação de qual decisão atuarial os originou.
Isso é o audit trail que não existe. Existem commits. Mas commit não é decisão rastreável: não diz quem do negócio autorizou, não diz qual nota técnica atuarial embasou a mudança, não diz a data de vigência com precisão formal.
A modelagem em DMN força a explicitação dessas decisões. Cada linha da tabela precisa de um critério de entrada definido e de uma saída determinística. Quando o analista não consegue especificar o critério claramente, o problema não está na modelagem: está na regra. Melhor descobrir isso antes de colocar em produção.
Do ponto de vista da engenharia, a externalização do motor de regras segue um padrão de integração relativamente direto. O serviço de negócio faz uma chamada ao motor com o contexto de decisão (variáveis de entrada), recebe o resultado (variáveis de saída) e continua o fluxo. O motor executa as regras versionadas, retorna o resultado e registra o log de decisão com a versão da regra aplicada.
O ponto de atenção técnico é a gestão de versão em produção. Quando o analista de negócio publica uma nova versão da tabela de decisão, o motor precisa saber qual versão aplicar para cada solicitação. Isso geralmente é resolvido por vigência: a nova versão entra em vigor a partir de uma data definida, e qualquer solicitação com data de referência anterior usa a versão correspondente. Para o ramo de seguros, isso é crítico. Uma apólice emitida com tabela de dezembro de 2025 precisa ser calculada com a tabela de dezembro de 2025, mesmo que em julho de 2026 a tabela já tenha sido atualizada três vezes.
A rastreabilidade gerada por esse mecanismo é precisamente o que a Resolução CNSP 395/2020 e a Circular SUSEP 667 demandam em termos de explicabilidade de decisões automatizadas. A fiscalização consegue perguntar "qual regra foi aplicada nessa apólice, em que data, com qual fator de risco" e obter uma resposta precisa. Com lógica hardcoded, a resposta disponível é o histórico de commits do repositório, que não mapeia decisões de negócio com data de vigência.
Depois que o primeiro módulo piloto está em produção e funcionando, o time passa por uma mudança de padrão operacional que vale registrar.
O analista de negócio para de abrir ticket para mudança de tabela. O tech lead para de ser interrompido às 17h por uma atualização de fator regional que precisa entrar antes do fechamento de amanhã. O desenvolvedor para de fazer QA em mudança de alíquota que, a rigor, nunca deveria ter passado por ele. O sprint fica com as features que sempre deveriam estar lá.
O que persiste no código é a lógica de integração e o fluxo de processo. O que sai do código é a inteligência de domínio que pertencia ao negócio desde o início e estava no código apenas por ausência de um lugar melhor para morar.
Uma seguradora de médio porte que percorreu esse caminho no ramo residencial relatou 70% de redução no tempo de revisão de regras e controle total da área de negócio sobre as alterações, sem dependência de engenharia para ajustes de subscrição e precificação. A equipe de TI deixou de ser o gargalo para virar o time que constrói o produto.
Regra muda. Sprint libera. Feature sai.
