Pipeline interno de validação sem repetir regra em toda borda

O problema

Muita equipe começa validando na borda.

Até aí, tudo bem.

O problema aparece quando cada nova entrada repete o pacote inteiro:

• API valida
• consumer valida de novo
• job de retry valida diferente
• script administrativo ignora metade

Resultado:

• o sistema aceita coisas diferentes dependendo da porta de entrada
• regras mudam em um lugar e quebram em outro
• ninguém sabe mais qual validação é “a certa”

Modelo mental

Vale separar pelo menos três camadas de validação:

• formato: estrutura mínima, tipos, campos obrigatórios
• admissibilidade: este chamador pode mandar isso? este evento pode entrar?
• regra de negócio: isso pode acontecer neste estado e neste contexto?

Nem tudo precisa morar no mesmo lugar.

Schema costuma ficar perto da borda.

Regra de negócio costuma ficar perto do caso de uso.

Exemplo simples

Imagine um sistema que cria cupons promocionais.

A API recebe:

• código
• data de expiração
• tipo de desconto
• limites de uso

Na borda faz sentido validar:

• formato da data
• presença de campos
• enum válido

Mas a regra:

• “não pode existir cupom com o mesmo código ativo para o mesmo tenant”
• “desconto percentual acima de certo valor exige aprovação”

não deveria ficar espalhada em controller, worker e script de backoffice.

Ela pertence ao núcleo do fluxo.

O erro comum

O erro comum é chamar tudo de validação e jogar em qualquer camada.

Daí acontecem duas coisas:

• regra de negócio vira if de adapter
• borda começa a decidir mais do que deveria

Outro erro comum é achar que repetir regra em toda borda aumenta segurança.

Às vezes só aumenta inconsistência.

Defesa em profundidade não é duplicar semântica por preguiça.

O que normalmente ajuda

Um pipeline interno melhor costuma deixar explícito:

• dado cru recebido
• dado estruturalmente aceito
• comando interno já normalizado
• decisão de negócio no caso de uso

Isso ajuda porque:

• entradas diferentes convergem para a mesma semântica
• mudança de regra não vira caça ao tesouro
• reprocessamento segue o mesmo núcleo

Quando API, fila e job convergem para o mesmo command interno, o sistema fica menos arbitrário.

Como um senior pensa

Quem tem mais julgamento costuma perguntar:

• isso é validação de formato ou regra do domínio?
• quantas entradas diferentes precisam respeitar esta mesma semântica?
• estou duplicando a regra ou traduzindo o dado para o mesmo modelo interno?
• o que acontece quando esse fluxo rodar fora da API?

Essa última pergunta costuma expor a arquitetura de verdade.

Ângulo de entrevista

Esse tema aparece em backend, modularização, jobs, integração e APIs.

O entrevistador quer ver se você entende:

• que nem toda validação é igual
• que borda não deveria concentrar regra de negócio
• que múltiplos caminhos de entrada precisam convergir para uma semântica comum

Resposta forte costuma soar assim:

“Eu separaria validação de formato da validação de regra. A borda garante schema e autenticidade mínima. O caso de uso decide se a operação faz sentido. Assim API, worker e reprocessamento reaproveitam a mesma semântica sem copiar regra em todo lugar.”

Takeaway direto

Pipeline de validação bom não valida tudo em todo lugar.

Ele valida a coisa certa na camada certa.