Regras de Negócio na Modelagem de Dados: como capturar, documentar e validar

O que é regra de negócio (e o que não é)

Regra de negócio é uma afirmação verificável sobre como a organização opera, o que é permitido, obrigatório ou proibido no domínio. Ela existe independentemente de tecnologia e costuma responder a perguntas como: “pode?”, “deve?”, “quando?”, “até quanto?”, “em que condições?”.

Decisão técnica é uma escolha de implementação feita para atender requisitos não funcionais (performance, escalabilidade, simplicidade, custo) ou limitações de plataforma. Ela pode mudar sem que o negócio mude.

Como diferenciar na prática

Armadilhas comuns

• Confundir regra com validação de UI: “campo obrigatório na tela” pode ser apenas uma decisão de interface; a regra real é “o dado é obrigatório para o processo”.
• Confundir regra com formato: “telefone com máscara (99) 99999-9999” é técnico; a regra pode ser “precisamos contatar o cliente por telefone válido”.
• Confundir regra com performance: “indexar coluna X” é técnico; a regra pode ser “consultas por X são críticas”.

Padrão de documentação de regras de negócio

Documentar regras com um padrão consistente evita ambiguidades e facilita rastreabilidade entre requisitos, modelo e validações. Abaixo está um template prático.

Template (campos obrigatórios)

• Identificador: código único (ex.: RN-CLI-001).
• Descrição: frase clara, testável, sem termos vagos.
• Motivação: por que existe (risco, lei, processo, auditoria, experiência do cliente).
• Exemplo: caso válido e inválido (ou antes/depois).
• Entidades/Atributos afetados: onde a regra impacta no modelo.
• Tipo de restrição: unicidade, obrigatoriedade, faixa, temporalidade, derivação (ou combinação).

Tipos de restrição (com sinais de identificação)

• Unicidade: “não pode repetir”, “um por”, “único”, “não pode haver dois”.
• Obrigatoriedade: “deve informar”, “é obrigatório”, “não pode ficar em branco”.
• Faixa/limite: “entre”, “no máximo”, “mínimo”, “até X”, “maior que”.
• Temporalidade: “a partir de”, “até”, “vigência”, “não pode no futuro”, “depois de”.
• Derivação: “é calculado”, “é a soma”, “depende de”, “é determinado por”.

Exemplos completos de regras documentadas

RN-CLI-001 — CPF único por cliente

• Identificador: RN-CLI-001
• Descrição: O CPF deve ser único para cada cliente ativo.
• Motivação: Evitar duplicidade de cadastro e inconsistências em faturamento e crédito.
• Exemplo: Válido: Cliente A com CPF 123.456.789-00. Inválido: Cliente B ativo com o mesmo CPF.
• Entidades/Atributos afetados: Cliente.cpf, Cliente.status
• Tipo de restrição: Unicidade (condicional por status)

RN-PED-004 — Pedido deve ter pelo menos 1 item

• Identificador: RN-PED-004
• Descrição: Um pedido só pode ser confirmado se possuir ao menos um item.
• Motivação: Evitar pedidos vazios que geram ruído operacional e financeiro.
• Exemplo: Válido: Pedido 1001 com 2 itens. Inválido: Pedido 1002 confirmado com 0 itens.
• Entidades/Atributos afetados: Pedido.status, ItemPedido
• Tipo de restrição: Obrigatoriedade (condicional ao evento “confirmar”)

RN-PRC-002 — Desconto máximo por item

• Identificador: RN-PRC-002
• Descrição: O desconto aplicado em um item não pode exceder 30% do valor unitário.
• Motivação: Controle de margem e prevenção de erro/fraude.
• Exemplo: Válido: valor 100, desconto 20. Inválido: valor 100, desconto 40.
• Entidades/Atributos afetados: ItemPedido.valor_unitario, ItemPedido.desconto
• Tipo de restrição: Faixa/limite

RN-ASS-007 — Assinatura não pode iniciar no passado

• Identificador: RN-ASS-007
• Descrição: A data de início de uma assinatura deve ser maior ou igual à data atual no momento da contratação.
• Motivação: Evitar inconsistências de cobrança e vigência contratual.
• Exemplo: Válido: início hoje. Inválido: início ontem.
• Entidades/Atributos afetados: Assinatura.data_inicio
• Tipo de restrição: Temporalidade

RN-FAT-010 — Total do pedido é derivado dos itens

• Identificador: RN-FAT-010
• Descrição: O total do pedido é calculado como a soma de (quantidade × (valor unitário − desconto)) de todos os itens.
• Motivação: Garantir consistência entre itens e total exibido/cobrado.
• Exemplo: Itens: (2×(50−0)) + (1×(100−10)) = 190.
• Entidades/Atributos afetados: Pedido.total, ItemPedido.quantidade, ItemPedido.valor_unitario, ItemPedido.desconto
• Tipo de restrição: Derivação

Passo a passo para capturar regras de negócio a partir de conversas e materiais

1) Colete “frases de regra” e marque palavras-gatilho

Durante entrevistas, leitura de políticas e análise de processos, destaque frases com: “deve”, “não pode”, “somente se”, “no máximo”, “a partir de”, “até”, “calculado por”.

2) Converta para uma frase testável

Troque termos vagos por condições objetivas.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Vago: “cliente precisa estar ok para comprar”.
• Testável: “um pedido só pode ser confirmado se o cliente estiver com status = 'ATIVO' e sem bloqueio financeiro”.

3) Identifique entidades/atributos afetados

Para cada regra, responda: “quais dados precisam existir para verificar isso?” e “onde isso aparece no modelo?”. Isso evita regras “soltas” sem ponto de controle.

4) Classifique o tipo de restrição

Classificar ajuda a decidir onde aplicar e como testar. Uma mesma regra pode ter mais de um tipo (ex.: obrigatoriedade + temporalidade).

5) Defina o momento de validação (evento)

Muitas regras não são “sempre verdade”, mas verdadeiras em um evento: criar, confirmar, faturar, cancelar, encerrar vigência. Documente explicitamente.

• Ex.: “Pedido deve ter item” pode ser exigido ao confirmar, não necessariamente ao criar rascunho.

6) Escreva exemplos válidos e inválidos

Exemplos concretos reduzem interpretações diferentes entre áreas. Use números e datas reais.

7) Valide com stakeholders e registre decisões

Apresente a regra no template e peça confirmação do texto e dos exemplos. Registre exceções e quem aprovou.

Onde aplicar cada regra: banco, aplicação ou processos

Uma regra pode ser aplicada em mais de um lugar. O objetivo é garantir consistência sem criar rigidez desnecessária.

Aplicar no banco (constraints, checks, índices únicos, triggers)

Use quando a regra precisa ser verdadeira independentemente de qual sistema grava os dados (múltiplas integrações, importações, jobs) e quando é uma restrição estrutural do dado.

• Boa candidata: unicidade simples, obrigatoriedade estrutural, faixas simples, integridade entre colunas da mesma linha.
• Cuidado: regras que dependem de contexto de processo (ex.: “ao confirmar”) ou que exigem consultas complexas podem ficar difíceis de manter no banco.

Exemplos (SQL ilustrativo):

-- Unicidade (simples): CPF único (se não houver condição por status no exemplo real, seria direto assim)  CREATE UNIQUE INDEX ux_cliente_cpf ON cliente(cpf);  -- Faixa: desconto entre 0 e 30% do valor unitário  ALTER TABLE item_pedido ADD CONSTRAINT ck_desconto_limite CHECK (desconto >= 0 AND desconto <= (valor_unitario * 0.30));  -- Temporalidade simples: data_inicio >= data atual (nem todo banco permite CURRENT_DATE em CHECK; pode exigir trigger)  

Aplicar na aplicação (serviços, domínio, validações de comando)

Use quando a regra depende do fluxo (estado), do usuário, de permissões, de cálculos complexos, ou quando precisa de mensagens de erro amigáveis e tratativas.

• Boa candidata: “só pode confirmar se…”, regras com múltiplas tabelas, regras com exceções por perfil, regras que mudam com frequência.
• Prática recomendada: centralizar validações em camada de domínio/serviço, não apenas na interface.

Exemplo de validação por evento:

Ao confirmar pedido:  - verificar se existe ao menos 1 item  - verificar se cliente está ATIVO  - verificar se total calculado confere com itens (se total for armazenado)  Se falhar, bloquear confirmação e retornar mensagem específica

Aplicar em processos (procedimentos operacionais, auditoria, conciliação)

Use quando a regra não é totalmente automatizável, quando depende de análise humana, ou quando o custo de bloquear transações é maior do que detectar e corrigir.

• Exemplos: revisão manual de pedidos acima de certo valor, auditoria mensal de cadastros duplicados, conciliação de faturamento.
• Importante: mesmo regras de processo devem ser documentadas no mesmo padrão, indicando que o mecanismo de controle é processual.

Guia rápido de decisão

Como validar regras com stakeholders (técnicas práticas)

Técnica 1: Cenários “válido vs inválido” (exemplos concretos)

Apresente a regra sempre com dois cenários mínimos: um que passa e um que falha. Peça ao stakeholder para dizer o que deveria acontecer em cada caso (aprovar, bloquear, pedir ajuste, abrir exceção).

Exemplo para RN-PRC-002:

• Caso A: item R$100, desconto R$25 → deve permitir?
• Caso B: item R$100, desconto R$35 → deve bloquear ou exigir aprovação?

Se surgir “exigir aprovação”, isso vira uma regra adicional (ex.: “acima de 30% exige aprovação de gerente”).

Técnica 2: Perguntas de fronteira (boundary questions)

Para regras de faixa e temporalidade, valide os limites exatos perguntando pelos valores de borda.

• “30% inclui 30,00% exatamente?”
• “Se a assinatura começa hoje às 23:59, é permitido?”
• “E se o cliente estiver inativo, mas com contrato em renovação?”

Registre a resposta como parte do exemplo ou como uma regra complementar.

Técnica 3: Tabela de decisão (quando há muitas condições)

Quando a regra depende de múltiplas condições (status, tipo, canal, perfil), use uma tabela de decisão para eliminar ambiguidades.

Depois, transforme a tabela em regras documentadas (uma regra principal + exceções, se existirem).

Técnica 4: Walkthrough do processo com “pontos de controle”

Desenhe (mesmo que em texto) as etapas do processo e marque onde cada regra é verificada. Isso ajuda stakeholders a perceberem regras que só fazem sentido em determinados eventos.

• Criar pedido (rascunho): permitir sem itens?
• Adicionar itens: validar desconto?
• Confirmar: exigir itens e cliente ativo?
• Faturar: congelar preços e impostos?

Técnica 5: Checklist de consistência (para evitar regras conflitantes)

Revise com stakeholders perguntas como:

• Existe exceção? Quem aprova?
• A regra vale para todos os canais (loja, app, integração)?
• O que acontece com dados antigos se a regra mudar?
• Qual mensagem/ação esperada quando a regra falha (bloquear, alertar, registrar ocorrência)?

Como transformar regras em validações verificáveis

Mapeie regra → mecanismo → teste

Para cada regra, registre também (mesmo que fora do template principal) como ela será garantida e como será testada.

Cuidados com regras condicionais e dados históricos

• Regra condicional: “único por cliente ativo” pode exigir índice parcial (quando suportado) ou estratégia alternativa (ex.: coluna de “ativo” no índice, ou tabela de identificadores ativos).
• Dados legados: antes de ativar constraints, rode diagnóstico para encontrar violações e combine plano de correção com stakeholders.
• Mudança de regra: documente vigência (“a partir de DD/MM/AAAA”) quando necessário; isso evita reprocessar histórico indevidamente.