Existe um vício oculto em projetos .NET que poucos questionam: usar enums para representar status, tipos e categorias, e depois espalhar if e switch por toda a base de código com base em deduções de regras implícitas.

if (grupo.Tipo == TipoGrupo.Administrador)
{
    // pode acessar tudo
}
else if (grupo.Tipo == TipoGrupo.Operador)
{
    // pode acessar quase tudo
}
else if (grupo.Tipo == TipoGrupo.Visualizador)
{
    // só leitura
}

Esse código parece inofensivo. Está limpo, compila, passa no code review. Mas ele carrega um problema estrutural que escala de forma destrutiva: o comportamento do sistema está implícito no código, não explícito no modelo.

Quem olha para o enum TipoGrupo não sabe quais permissões cada tipo carrega. Quem olha para o banco de dados não encontra essa informação. Quem precisa adicionar um novo tipo precisa caçar todos os if e switch espalhados pela aplicação para entender o que precisa implementar.

Isso não é modelagem. É arqueologia.

o problema real: enums escondem especificações inteiras

Um enum em C# é, na essência, um inteiro com um apelido, um nome. Ele não carrega semântica, não expressa capacidades, não declara limites. Toda a inteligência que deveria estar associada àquele valor vive em outro lugar — dispersa em condicionais, enterrada em services, duplicada entre controllers e workers.

Considere um sistema de pedidos com status:

public enum StatusPedido
{
    Rascunho,
    Confirmado,
    EmProcessamento,
    Enviado,
    Entregue,
    Cancelado
}

Parece completo. Mas esse enum não responde a nenhuma pergunta relevante sobre comportamento:

• Quais status permitem cancelamento?
• Em quais status o pedido pode ser editado?
• Quais status geram notificação ao cliente?
• Quais transições de status são válidas?

Essas respostas estão espalhadas pelo código. E cada desenvolvedor que precisa dessa informação faz a mesma jornada: abre o repositório, busca por StatusPedido, lê dezenas de arquivos, monta mentalmente o mapa de comportamentos, e torce para não ter esquecido nenhum caso.

Quando um status novo precisa ser adicionado — digamos, AguardandoRetirada — o desenvolvedor adiciona o valor no enum e… começa a caçada. Cada switch precisa ser revisado. Cada if que compara com StatusPedido.Enviado pode precisar incluir o novo status. E se algum for esquecido, o bug não aparece na compilação. Aparece em produção.

Isso viola frontalmente o Open/Closed Principle: o sistema deveria ser aberto para extensão e fechado para modificação. Adicionar um novo tipo ou status não deveria exigir alteração de código existente. Mas com enums, cada novo valor é uma cirurgia em toda a base de código.

Alternativa: Discriminadores de Comportamento

A solução não é complexa. É uma mudança de perspectiva na modelagem: em vez de tratar status e tipos como constantes opacas, modelamos como entidades que declaram seus próprios comportamentos.

Em vez disso:

Tabela: Pedidos
- Id
- StatusPedidoId (int, FK → ?)
- ...

Enum no código: StatusPedido { Rascunho = 1, Confirmado = 2, ... }

Fazemos isso:

CREATE TABLE StatusPedido (
    Id INT PRIMARY KEY,
    Nome VARCHAR(50) NOT NULL,
    PermiteCancelamento BIT NOT NULL DEFAULT 0,
    PermiteEdicao BIT NOT NULL DEFAULT 0,
    NotificaCliente BIT NOT NULL DEFAULT 0,
    ExigeAprovacao BIT NOT NULL DEFAULT 0,
    Ativo BIT NOT NULL DEFAULT 1
);

INSERT INTO StatusPedido (Id, Nome, PermiteCancelamento, PermiteEdicao, NotificaCliente, ExigeAprovacao)
VALUES
    (1, 'Rascunho',          1, 1, 0, 0),
    (2, 'Confirmado',        1, 0, 1, 0),
    (3, 'Em Processamento',  0, 0, 0, 0),
    (4, 'Enviado',           0, 0, 1, 0),
    (5, 'Entregue',          0, 0, 1, 0),
    (6, 'Cancelado',         0, 0, 1, 0);

Agora cada status declara explicitamente o que permite e o que não permite. Não existe dedução. Não existe interpretação. A especificação está no dado, não no código.

O mesmo princípio para tipos: flags de comportamento

Voltando ao exemplo do tipo de grupo. Em vez de perguntar “este grupo é do tipo Administrador?”, perguntamos “este tipo de grupo possui a capacidade de administração?”:

CREATE TABLE TipoGrupo (
    Id INT PRIMARY KEY,
    Nome VARCHAR(50) NOT NULL,
    Administrador BIT NOT NULL DEFAULT 0,
    PodeGerenciarUsuarios BIT NOT NULL DEFAULT 0,
    PodeAcessarRelatorios BIT NOT NULL DEFAULT 0,
    PodeAlterarConfiguracoes BIT NOT NULL DEFAULT 0
);

INSERT INTO TipoGrupo (Id, Nome, Administrador, PodeGerenciarUsuarios, PodeAcessarRelatorios, PodeAlterarConfiguracoes)
VALUES
    (1, 'Administrador', 1, 1, 1, 1),
    (2, 'Operador',      0, 0, 1, 1),
    (3, 'Visualizador',  0, 0, 1, 0),
    (4, 'Suporte',       0, 1, 1, 0);

A diferença é sutil na estrutura, mas profunda no impacto. Agora, quando o sistema precisa saber se um grupo pode gerenciar usuários, a pergunta é direta:

if (grupo.Tipo.PodeGerenciarUsuarios)
{
    // comportamento permitido
}

Não estamos mais perguntando quem o grupo é. Estamos perguntando o que o grupo pode fazer. Essa distinção elimina a necessidade de conhecer a lista de tipos para implementar lógica. O código se torna agnóstico ao tipo específico e reage às capacidades declaradas.

Quem se beneficia dessa abordagem?

Esse princípio deq ue “comportamentos não podem ser deduzidos” se aplica a qualquer entidade que carrega regras implícitas avaliadas por condicionais no código. Além de status e tipos, os candidatos mais óbvios:

Perfis e papéis (roles) — o clássico if (usuario.Role == "Admin") espalhado por dezenas de controllers. Flags como PodeAprovar, PodeExcluir, AcessaRelatorios tornam as capacidades do papel explícitas e extensíveis sem tocar em código.

Categorias de produto/serviço — quando a categoria define comportamento fiscal, logístico ou de precificação. Em vez de if (produto.Categoria == Categoria.Digital) para pular cálculo de frete, uma flag ExigeFrete na tabela de categorias.

Planos e níveis de assinatura (tiers) — if (plano == Plano.Premium) para liberar funcionalidades. Flags como PermiteExportacao, LimiteUsuarios, SuportePrioritario tornam cada plano autodescritivo.

Modalidades de pagamento — em vez de deduzir que boleto exige compensação assíncrona e cartão é síncrono, flags como CompensacaoAssincrona, PermiteEstorno, ExigeConfirmacao.

Tipos de documento/contrato — quando o tipo define fluxo de aprovação, validade, necessidade de assinatura digital. Flags como ExigeAssinatura, TemValidade, RequerAprovacao.

Severidades e prioridades (em sistemas de incidentes, tickets, alertas) — em vez de if (severidade == Severidade.Critica) para decidir se notifica por SMS, flags como NotificaSMS, EscalaAutomaticamente, BloqueiaDeploy.

Etapas de pipeline/workflow — qualquer sistema com fluxo de etapas onde cada etapa habilita ou bloqueia ações. Flags como PermiteRetrocesso, ExigeAnexo, GeraTarefa.

Tipos de evento em event-driven — quando o tipo do evento determina se ele exige retry, se é idempotente, se deve ir para dead letter após falha. Flags como Idempotente, RetryAutomatico, CriticoParaConsistencia.

O padrão é sempre o mesmo: se existe um if no código que avalia a identidade da entidade para deduzir um comportamento, esse comportamento deveria ser um discriminador explícito na tabela que define aquela entidade. A pergunta não é “quem é”, é “o que declara que pode fazer”.

Antes e Depois com C#

Antes: comportamento implícito, acoplado ao valor do enum

public class PedidoService
{
    public async Task CancelarAsync(Pedido pedido)
    {
        // quem decidiu que esses status permitem cancelamento?
        // onde está essa especificação?
        // se um novo status surgir, quem vai lembrar de atualizar aqui?
        if (pedido.Status != StatusPedido.Rascunho && 
            pedido.Status != StatusPedido.Confirmado)
        {
            throw new InvalidOperationException(
                "Pedido não pode ser cancelado no status atual.");
        }

        pedido.Status = StatusPedido.Cancelado;
        await _repository.AtualizarAsync(pedido);
    }

    public async Task EditarAsync(Pedido pedido, DadosPedido dados)
    {
        // mesma lógica espalhada em outro lugar
        if (pedido.Status != StatusPedido.Rascunho)
        {
            throw new InvalidOperationException(
                "Pedido não pode ser editado no status atual.");
        }

        pedido.Aplicar(dados);
        await _repository.AtualizarAsync(pedido);
    }

    public async Task NotificarClienteAsync(Pedido pedido)
    {
        // e aqui mais uma lista de status que "alguém sabe" que notifica
        if (pedido.Status == StatusPedido.Confirmado ||
            pedido.Status == StatusPedido.Enviado ||
            pedido.Status == StatusPedido.Entregue ||
            pedido.Status == StatusPedido.Cancelado)
        {
            await _notificacaoService.EnviarAsync(pedido);
        }
    }
}

Três métodos, três listas de status hardcoded, zero rastreabilidade. Se um status novo for adicionado ao enum, o compilador não reclama. O sistema simplesmente se comporta de forma errada — silenciosamente.

Depois: comportamento declarativo, dirigido por dados

public class StatusPedidoEntity
{
    public int Id { get; set; }
    public string Nome { get; set; }
    public bool PermiteCancelamento { get; set; }
    public bool PermiteEdicao { get; set; }
    public bool NotificaCliente { get; set; }
    public bool ExigeAprovacao { get; set; }
}

public class PedidoService
{
    public async Task CancelarAsync(Pedido pedido)
    {
        if (!pedido.Status.PermiteCancelamento)
        {
            throw new InvalidOperationException(
                $"Status '{pedido.Status.Nome}' não permite cancelamento.");
        }

        pedido.Status = await _statusRepository
            .ObterPorNomeAsync("Cancelado");
        await _repository.AtualizarAsync(pedido);
    }

    public async Task EditarAsync(Pedido pedido, DadosPedido dados)
    {
        if (!pedido.Status.PermiteEdicao)
        {
            throw new InvalidOperationException(
                $"Status '{pedido.Status.Nome}' não permite edição.");
        }

        pedido.Aplicar(dados);
        await _repository.AtualizarAsync(pedido);
    }

    public async Task NotificarClienteAsync(Pedido pedido)
    {
        if (pedido.Status.NotificaCliente)
        {
            await _notificacaoService.EnviarAsync(pedido);
        }
    }
}

O código encolheu, ficou mais legível e — o mais importante — parou de mentir. Não existem mais listas secretas de status que permitem ou proíbem ações. A verdade está na tabela. O código apenas pergunta.

O impacto em escala: da UI ao worker

Quando comportamentos estão declarados em dados, o benefício não se limita ao backend. Ele permeia toda a aplicação:

Na API, o endpoint que retorna um pedido pode incluir as capacidades do status atual. O frontend não precisa replicar lógica — recebe permiteCancelamento: true e renderiza ou esconde o botão.

No worker, o consumidor que processa eventos pode consultar flags do status para decidir se executa uma ação, sem carregar regras hardcoded que precisam ser sincronizadas com o backend.

Na documentação, a tabela de status com suas flags é, por si só, uma especificação funcional. Um product owner consegue ler a tabela e validar se os comportamentos estão corretos — sem ler código.

No onboarding, um desenvolvedor novo consulta uma tabela e entende imediatamente quais comportamentos cada status habilita. Não precisa fazer arqueologia em dezenas de arquivos para montar o mapa mental.

transições de status: o próximo passo natural

Se status declaram comportamentos, o passo seguinte é declarar também as transições válidas:

CREATE TABLE TransicaoStatusPedido (
    StatusOrigemId INT NOT NULL,
    StatusDestinoId INT NOT NULL,
    ExigeAprovacao BIT NOT NULL DEFAULT 0,
    PRIMARY KEY (StatusOrigemId, StatusDestinoId),
    FOREIGN KEY (StatusOrigemId) REFERENCES StatusPedido(Id),
    FOREIGN KEY (StatusDestinoId) REFERENCES StatusPedido(Id)
);

INSERT INTO TransicaoStatusPedido (StatusOrigemId, StatusDestinoId, ExigeAprovacao)
VALUES
    (1, 2, 0),  -- Rascunho → Confirmado
    (2, 3, 0),  -- Confirmado → Em Processamento
    (3, 4, 0),  -- Em Processamento → Enviado
    (4, 5, 0),  -- Enviado → Entregue
    (1, 6, 0),  -- Rascunho → Cancelado
    (2, 6, 1);  -- Confirmado → Cancelado (exige aprovação)

Agora a máquina de estados inteira é declarativa. Validar uma transição no código se reduz a uma consulta:

public async Task TransicionarAsync(Pedido pedido, int novoStatusId)
{
    var transicao = await _transicaoRepository
        .ObterAsync(pedido.Status.Id, novoStatusId);

    if (transicao is null)
    {
        throw new InvalidOperationException(
            $"Transição de '{pedido.Status.Nome}' para o status " + 
            $"destino não é permitida.");
    }

    if (transicao.ExigeAprovacao)
    {
        await _aprovacaoService.SolicitarAsync(pedido, novoStatusId);
        return;
    }

    pedido.Status = await _statusRepository.ObterAsync(novoStatusId);
    await _repository.AtualizarAsync(pedido);
}

Adicionar um novo status? Insere na tabela e define as transições. Zero alteração no código. Open/Closed honrado, não na teoria.

É para abolir o uso de Enums? Quando o enum ainda faz sentido

Seria desonesto dizer que enums não têm lugar. Eles são adequados quando o valor é genuinamente estático, sem comportamento associado e sem expectativa de extensão: dias da semana, unidades de medida, direções cardeais. Valores que são constantes universais, não regras de negócio disfarçadas.

O problema não é o enum como estrutura de dados. É o uso do enum como veículo de especificação implícita. Quando cada valor carrega consigo um conjunto de regras que só existem nos if do código, o enum deixou de ser uma constante e virou uma especificação escondida.

Checklist: como identificar enums que deveriam ser tabelas?

Se pelo menos uma das condições abaixo for verdadeira, o enum é candidato a ser promovido para tabela com flags de comportamento:

• Existe pelo menos um if ou switch no código que avalia o valor do enum para decidir um comportamento.
• Adicionar um novo valor ao enum exige alteração em mais de um arquivo.
• O significado de cada valor do enum precisa ser explicado verbalmente para novos desenvolvedores — não é autoevidente.
• O mesmo enum é avaliado em camadas diferentes da aplicação (API, serviço, worker) com lógicas que precisam estar sincronizadas.
• O product owner ou analista de negócio não consegue validar as regras associadas ao enum sem ler código.

Se três ou mais dessas condições são verdadeiras, não é uma questão de preferência. É débito técnico ativo.

Conclusão

Enums em C# são uma ferramenta de representação, não de modelagem. Quando usamos enums para carregar regras de negócio, estamos escolhendo conveniência no momento da escrita em troca de obscuridade permanente na manutenção.

Cada if (entidade.Status == Status.XPTO) é uma regra de negócio que existe apenas na memória de quem escreveu aquele código. Quando essa pessoa sai do time, a regra vira folclore. Quando o sistema cresce, o folclore vira risco operacional.

Promover status e tipos para tabelas com comportamento declarado não é overengineering. É tornar explícito o que já existe — só que escondido nos lugares errados.

A pergunta que todo arquiteto deveria fazer ao revisar um modelo de domínio é simples: se eu apagar todo o código e olhar apenas para o banco de dados, consigo entender o que o sistema permite e o que ele proíbe?

Se a resposta é não, os dados estão incompletos. E nenhuma quantidade de if no código compensa um modelo que não se explica sozinho.