Parte 6 - Regras como dados: criando sua própria linguagem declarativa (Copy)

Até aqui, construímos uma engine de execução baseada em JSON, capaz de executar ações, reagir a condicionais e trabalhar com plugins. Agora, chegou o momento de dar um nome mais formal a isso tudo: você está criando uma linguagem.

Sim, uma linguagem declarativa. E não precisa parecer com o LISP nem com nenhuma linguagem esotérica. Pode ser simples, intuitiva, visual ou baseada em estruturas conhecidas como JSON ou YAML.

O que significa transformar regras em dados?

Significa abandonar o código como local exclusivo da lógica e permitir que o comportamento do sistema seja controlado por estruturas que você define externamente.

Em vez de:

if Produto.EmEstoque then
  Separar(Produto)
else
  NotificarIndisponivel(Produto);

Você escreve:

{
  "se": { "produto.emEstoque": true },
  "entao": [ { "acao": "SepararProduto" } ],
  "senao": [ { "acao": "NotificarIndisponivel" } ]
}

E seu sistema interpreta isso. Ou seja: as regras agora são dados.

Por que criar sua própria linguagem?

Porque linguagens declarativas são:

• Mais fáceis de ler por não-programadores
• Fáceis de versionar e testar
• Independentes do código compilado
• Expressivas e reconfiguráveis em tempo real

E principalmente: porque você controla a complexidade.

Componentes de uma linguagem declarativa leve

1. Vocabulário de ações ("EnviarEmail", "AtualizarStatus")
2. Condicionais ("se", "senao")
3. Contexto de execução (variáveis internas)
4. Parâmetros nomeados
5. Fallbacks ou comportamentos padrão
6. Sequenciamento (ordem de execução)
7. (Opcional) Loops ou repetições

Como começar a projetar sua DSL

1. Defina os conceitos chave do seu negócio.
   • Ex: Pedido, Cliente, Estoque, Notificação
2. Dê nomes simples e consistentes às ações.
   • Ex: "EnviarEmail", "SepararProduto", "BaixarEstoque"
3. Modele o formato em JSON ou YAML.
   • Use uma estrutura intuitiva, que você possa interpretar com um for e um if.
4. Implemente um interpretador genérico.
   • Capaz de ler as regras, avaliar condições e executar as ações
5. Evite expressividade excessiva.
   • Quanto mais simples, mais legível e segura é sua linguagem.

Exemplo de regra com contexto e fallback

{
  "acao": "AplicarDesconto",
  "condicional": {
    "se": { "cliente.vip": true },
    "entao": [ { "acao": "Desconto", "valor": 20 } ],
    "senao": [ { "acao": "Desconto", "valor": 5 } ]
  }
}

Quando não criar uma linguagem declarativa

• Quando você tem poucos casos de uso
• Quando todos os fluxos estão bem definidos e raramente mudam
• Quando não há equipe ou tempo para manter a interpretação

Conclusão

Regras como dados não são uma moda. São uma evolução natural em sistemas que precisam mudar o tempo todo sem recomeçar do zero.

Criar sua própria linguagem não é reinventar a roda. É moldar uma roda sob medida para o seu terreno.

Quanto mais declarativo é seu sistema, mais vivo ele se torna. E código vivo é aquele que muda junto com o mundo, sem pedir desculpas.

Próximo artigo sugerido: "Mini Engine: como encapsular toda essa lógica em um framework reaproveitável"