Procedures armazenadas vs workflows visuais: onde a lógica deve morar

O que essa decisão realmente significa

Lógica de negócio é o conjunto de regras que decide o que é permitido, o que acontece em seguida e o que o sistema deve fazer quando pessoas reais o usam. Não é o dado em si. É o comportamento: quem pode fazer o quê, em quais condições e com quais efeitos colaterais.

Então a discussão sobre procedures armazenadas vs workflows visuais é, na verdade, sobre onde essas regras devem morar para que continuem fáceis de mudar, difíceis de quebrar e claras para quem é dono do processo.

A maioria das equipes acaba com três “lares” possíveis para a lógica:

• No banco de dados (procedures armazenadas, triggers, constraints): regras que rodam perto dos dados. Isso pode ser rápido e consistente, mas mais difícil de alterar por quem não é especialista em banco de dados.
• Em workflows visuais (construtores de processos drag-and-drop): regras expressas como passos e decisões. Geralmente é mais fácil de ler, revisar e ajustar conforme o processo muda.
• Em código customizado (serviços, apps, scripts): regras escritas numa linguagem de programação. Dá máxima flexibilidade, mas mudanças costumam exigir mais disciplina de engenharia e testes.

A escolha afeta a velocidade do dia a dia e a manutenção no longo prazo. Coloque lógica no lugar errado e você terá entrega lenta (cada mudança precisa da pessoa que conhece o banco), mais erros (regras duplicadas em vários lugares) e debugging doloroso (ninguém sabe por que um registro foi rejeitado).

A maioria dos sistemas contém vários tipos de lógica de negócio. Exemplos comuns incluem validação (campos obrigatórios, intervalos permitidos), aprovações, precificação e descontos, notificações e regras de acesso.

Uma forma prática de pensar: o banco é ótimo em proteger integridade dos dados, workflows visuais são ótimos em expressar processos de negócio, e código customizado é ótimo quando a regra é muito única ou complexa para modelar claramente. Plataformas como AppMaster ficam fortemente no meio: você pode modelar dados e implementar o processo como lógica visual legível sem espalhar regras por muitos apps.

Os critérios: o que você está otimizando

Não é só uma questão de gosto. É sobre o que você está tentando proteger: os dados, as pessoas que mudam o sistema e a velocidade de mudança.

Os resultados que mais importam

Nomeie os principais resultados para o seu projeto. A maioria das equipes equilibra uma mistura destes:

• Corretude: as regras devem rodar do mesmo jeito toda vez, mesmo sob carga.
• Clareza: alguém novo deve entender o que acontece sem chutar.
• Velocidade: a lógica precisa rodar rápido e perto dos dados quando necessário.
• Auditabilidade: você precisa provar quem mudou o quê e quando rodou.
• Taxa de mudança: você espera requisitos mudando semanalmente, não anualmente.

Raramente você maximiza os cinco. Aproximar a lógica do banco pode melhorar corretude e velocidade, mas reduzir clareza para quem não vive em SQL.

Quem vai mudar a lógica (e com que frequência)

Seja honesto sobre quem será o dono das mudanças no dia a dia. Uma regra que o time de operações precisa ajustar toda semana não deveria exigir um DBA para fazer deploy de uma procedure. Ao mesmo tempo, uma regra que afeta dinheiro não deveria ser editável sem revisão.

Pense em termos de atrito de mudança. Se requisitos mudam com frequência, você quer um lugar onde atualizações sejam seguras, visíveis e rápidas de entregar. Ferramentas visuais (por exemplo, o Business Process Editor do AppMaster) funcionam bem quando donos de produto e engenheiros precisam colaborar na lógica sem editar código de baixo nível. Se mudanças são raras e a regra é crítica, atrito maior é aceitável.

Uma maneira rápida de pressionar a propriedade:

• Quem recebe o chamado quando quebra às 2 da manhã?
• Quão rápido você precisa corrigir uma regra?
• Mudanças precisam de aprovações ou trilha em papel?
• Vários apps dependerão da mesma regra?
• A lógica é mais modelagem de dados ou decisões de negócio?

Anote restrições cedo. Algumas indústrias exigem controle de acesso rigoroso, separação de funções ou logs detalhados. Considere também limites de acesso a dados: se apenas certos serviços devem ver campos específicos, isso afeta onde a lógica pode rodar com segurança.

Quando a lógica pertence a procedures armazenadas

Procedures armazenadas são trechos de lógica que rodam dentro do banco de dados. No PostgreSQL, são escritas em SQL (e às vezes numa linguagem de banco como PL/pgSQL). Em vez de seu app puxar linhas, iterar e empurrar mudanças de volta, o banco faz o trabalho onde os dados vivem.

Uma boa regra é simples: coloque a lógica no banco quando o trabalho principal for proteger dados e fazer trabalho em lote, não coordenar pessoas ou sistemas.

Onde procedures armazenadas brilham

Procedures são uma boa escolha para regras que devem ser verdadeiras sempre, não importa qual app ou integração toque o banco. Pense em guardrails que mantêm dados ruins fora.

Elas também se destacam em atualizações set-based, onde uma instrução pode atualizar milhares de linhas com segurança e rapidez. Cálculos simples que são puramente sobre dados, como calcular totais ou aplicar uma fórmula fixa de desconto, também podem morar aqui quando reduz round trips e mantém resultados consistentes.

Exemplo: quando um pedido é marcado como paid, uma procedure pode atualizar atomically o status do pedido, decrementar o inventário e gravar uma linha de auditoria. Se qualquer passo falhar, toda a mudança é revertida.

Quando procedures armazenadas ficam arriscadas

Procedures podem ser mais difíceis de testar e versionar do que código de aplicação, especialmente se sua equipe não tratar mudanças no banco como releases reais. A lógica também pode ficar “escondida” do app, criando acoplamento que você só descobre depois.

Debugar fica mais complicado. Erros podem aparecer como mensagens do banco com menos contexto sobre o que o usuário fez. Novos colegas podem sofrer porque as regras estão divididas entre app e banco, e lógica no banco é fácil de perder durante o onboarding.

Se você usa uma ferramenta visual para a maior parte da lógica, reserve procedures armazenadas para o núcleo pequeno e estável que deve rodar perto dos dados. Mantenha o resto onde seja mais fácil de ler, rastrear e mudar.

Quando a lógica cabe melhor em workflows visuais

Workflows visuais são lógica de processo passo a passo que você pode ler como uma checklist: quando algo acontece, execute estas ações nessa ordem, com pontos de decisão claros. Eles são menos sobre cálculo pesado e mais sobre como o trabalho passa por pessoas, sistemas e tempo.

Eles brilham quando você se importa com entendimento compartilhado. Se produto, ops, suporte e engenharia precisam concordar em como um processo funciona, um workflow visual torna as regras visíveis. Essa visibilidade costuma ser a diferença entre “o sistema quebrou” e “o processo mudou semana passada.”

Workflows visuais costumam ser adequados para aprovações e revisões, roteamento, notificações e lembretes, passos temporizados (esperar 2 dias, então escalar) e integrações (chamar Stripe, enviar uma mensagem, atualizar um CRM).

Exemplo: um cliente solicita um reembolso. O workflow checa a idade do pedido, roteia para um gerente se estiver acima do limite, notifica financeiro quando aprovado e envia uma atualização ao cliente. Cada passo é fácil de apontar e discutir em linguagem simples, o que ajuda stakeholders a aprovarem e novos membros a entenderem o “porquê”.

Ferramentas como o Business Process Editor do AppMaster são feitas para esse tipo de lógica: você vê o caminho, as condições e os efeitos colaterais (mensagens, chamadas de API, mudanças de status) sem procurar por scripts no banco.

Para evitar que workflows virem um emaranhado, mantenha-os pequenos e legíveis. Dê a cada workflow um resultado, use nomes claros para passos e ramos, limite decisões profundamente aninhadas e registre escolhas-chave para poder responder “por que isso aconteceu?” depois.

Quando um workflow começa a fazer crunch de dados complexo ou tocar muitas tabelas, isso costuma ser um sinal para mover parte da lógica para outro lugar. Workflows visuais funcionam melhor como o maestro, não como toda a orquestra.

Quando código customizado é a ferramenta certa

Código customizado é lógica que você escreve e mantém como software: funções, serviços ou pequenas bibliotecas que rodam como parte do seu app. É a opção mais flexível, e por isso deve ser usada de propósito, não por padrão.

Código compensa quando a lógica é difícil de expressar com segurança em uma procedure do banco ou num workflow drag-and-drop. Se você se pega forçando ferramentas a caber no problema, código costuma ser mais claro e mais fácil de manter correto.

Sinais fortes para usar código:

• O problema é algorítmico (regras de preço, roteamento, scoring, matching, checagens de fraude) e tem muitos casos de borda.
• Você precisa de uma integração incomum (uma API parceira com autenticação estranha, retries complexos, regras rigorosas de idempotência).
• Performance é sensível (processamento em alto volume, cálculos pesados, cache rigoroso) e você precisa de controle fino.
• Você deve compartilhar a mesma lógica em vários lugares (web, mobile, jobs em lote) sem copiar.
• Você precisa de testes automatizados fortes em torno da lógica porque erros são caros.

Código também deixa a propriedade mais clara. Um time pode ser responsável por revisar mudanças, manter testes verdes e documentar comportamento. Isso é melhor do que “vive em três workflows e ninguém tem certeza de qual roda primeiro.”

Exemplo: um motor de decisão de reembolso que considera histórico de pedidos, sinais de fraude, status de envio e janelas de tempo. Você pode manter passos de aprovação em um workflow visual, mas a decisão em si costuma ser melhor como código com unit tests e version control.

O custo é real. Código customizado precisa de tempo de engenharia, revisões e manutenção contínua. Mudanças podem demorar mais do que editar um workflow, e você precisa de um processo de release. AppMaster pode reduzir quanto código você precisa cobrindo partes comuns com lógica visual e módulos, enquanto ainda permite exportar source code e estender onde for necessário.

Um framework passo a passo que você pode reutilizar

Equipes frequentemente pulam a parte mais útil: escrever a regra claramente, então escolher um lar que combine com como a regra se comporta.

Use este framework sempre que aparecer uma nova regra:

• Escreva a regra numa frase e rotule-a. Se for sobre dados válidos (constraints, unicidade, totais que devem bater), é uma regra de dados. Se for sobre passos e repasses (aprovações, esperas, notificações), é uma regra de processo. Se for matemática pesada ou transformações complexas, é uma regra de computação.
• Pergunte quem edita e com que frequência. Se pessoas não técnicas devem mudar semanalmente, não enterre em SQL ou release de código. Se raramente muda e precisa ser aplicada sempre, o banco é candidato mais forte.
• Verifique o impacto de falha e a trilha de auditoria necessária. Se um erro pode causar perda de dinheiro, problemas de conformidade ou dados difíceis de consertar, prefira um lugar com logging claro e controle rígido.
• Escolha a localização e defina o limite. Seja explícito sobre inputs, outputs e erros. Exemplo: “Dado um order_id, retorne allowed_refund_amount ou um motivo claro.” Esse limite evita que a lógica vaze por todo lado.
• Escolha uma camada para manter fina. Decida o que deve ser principalmente “burro” para não duplicar regras. Escolhas comuns: deixar o banco fino (só integridade de dados), deixar workflows finos (apenas orquestração) ou deixar o código fino (apenas cola).

Regra prática: coloque regras de dados perto dos dados, coloque regras de processo em uma ferramenta de workflow e coloque regras de computação onde for mais fácil testar e versionar.

Se estiver usando uma plataforma como AppMaster, trate o banco como guardrails (tabelas, relacionamentos, constraints básicas), use o Business Process Editor visual para “quem faz o quê em seguida” e reserve código customizado para os poucos casos que realmente precisam.

Erros comuns que causam sistemas bagunçados

Sistemas bagunçados raramente acontecem por uma escolha ruim isolada. Acontecem quando a lógica fica espalhada, escondida ou copiada até que ninguém saiba o que o sistema realmente faz.

Duplicação é o problema clássico: a mesma regra existe em dois lugares, mas elas divergem com o tempo. Exemplo: o banco rejeita reembolsos acima de $500 a menos que exista um registro de aprovação, mas um workflow ainda envia a requisição de pagamento porque verifica um limite diferente. Ambos “funcionam” até o primeiro caso de borda real, então o suporte ganha um bug misterioso.

Regras escondidas vêm em seguida. Triggers, procedures e correções rápidas no banco podem ser invisíveis para quem constrói a UI ou workflows. Se a regra não estiver documentada perto do workflow ou da API que depende dela, mudanças viram chute e testes viram tentativa e erro.

Workflows inchados criam outro tipo de bagunça. Uma cadeia longa de drag-and-drop com dezenas de ramos vira um artefato frágil que ninguém quer tocar. Em ferramentas como AppMaster é fácil ir adicionando blocos porque é rápido, mas velocidade hoje pode virar confusão depois se o workflow não tiver limites claros.

Dois erros opostos de “demais” causam dor no longo prazo:

• Demais no banco: cada mudança de política vira projeto de migração, e pequenos ajustes de produto esperam releases do banco.
• Demais no código do app: regras básicas de dados (campos obrigatórios, status permitidos, constraints de unicidade) são esquecidas, e dados ruins entram por importações, ferramentas administrativas ou integrações futuras.

Um hábito simples previne a maior parte disso: mantenha cada regra em um lar primário e escreva onde ela vive e por quê. Se você não consegue responder “onde isso é imposto?” em 10 segundos, você já está pagando o imposto da bagunça.

Verificações rápidas: decida em 2 minutos

Você está escolhendo onde uma regra é mais fácil de manter correta, visível e mutável.

Comece com uma pergunta: essa regra é sobre correção de dados, isto é, precisa nunca ser contornada? Se sim, empurre para mais perto do banco. Se for sobre passos, aprovações ou notificações, mantenha mais perto da camada de workflow.

Uma checklist rápida:

• Está impondo correção de dados (evitar inventário negativo, bloquear registros “ativos” duplicados)? Pule pro banco.
• Toca muitas tabelas e precisa de updates set-based (muitas linhas de uma vez)? Banco.
• Precisa de trilha humana legível de quem aprovou o quê e quando? Workflow.
• Pessoas não técnicas precisarão mudar semanalmente ou mensalmente? Workflow.
• Chama serviços externos (pagamentos, mensagens, AI)? App ou workflow, não o banco.

Agora pense na falha. Uma regra que pode falhar deve falhar de um jeito que humanos possam recuperar.

Se você precisa de retries seguros e mensagens de erro claras, prefira uma camada de orquestração onde consiga rastrear estado e tratar exceções passo a passo. Ferramentas visuais muitas vezes tornam isso mais fácil porque cada passo é explícito e pode ser logado.

Um desempate prático:

• Se o sistema deve permanecer correto mesmo quando alguém escrever um app novo depois, aplique no banco.
• Se o processo deve ser lido e revisado por times de ops, mantenha em um workflow visual.
• Se envolve integrações complexas, computação pesada ou bibliotecas especiais, use código customizado.

Exemplo: “O valor do reembolso não pode exceder o pagamento original” é correção, então aplique perto dos dados. “Reembolsos acima de $500 exigem aprovação de gerente e então enviam uma mensagem no Telegram” é workflow. No AppMaster, essa cadeia de aprovação cabe naturalmente no Business Process Editor, enquanto constraints estritas ficam no modelo de dados.

Cenário de exemplo: reembolsos com aprovações

Um caso real comum é um reembolso que precisa de aprovação de gerente acima de certo valor, mais notificações e um rastro de auditoria limpo.

Comece definindo uma única fonte de verdade: um registro Refund com valores e um campo de status claro (por exemplo: requested, needs_approval, approved, rejected, processing, paid, failed). Todas as partes do sistema devem ler e escrever nesses mesmos campos, em vez de manter estados paralelos em diferentes lugares.

O que pertence ao banco

Coloque as regras que protegem dinheiro e consistência de dados o mais perto possível dos dados.

Use constraints (e às vezes uma procedure) para garantir que você não possa reembolsar mais do que o valor capturado, reembolsar um pedido já totalmente reembolsado, criar dois pedidos ativos de reembolso para o mesmo pedido, ou alterar valores-chave depois que o reembolso for aprovado.

Também mantenha a atualização atômica aqui: quando um pedido de reembolso é criado, escreva a linha Refund e atualize os totais do Order numa única transação. Se qualquer gravação falhar, nada deve ficar parcialmente atualizado.

O que cabe melhor em um workflow visual

Passos de aprovação são processo, não proteção de dados. Um workflow visual é um bom lar para rotear a requisição ao gerente certo, esperar uma decisão, atualizar status, enviar lembretes e notificar o solicitante.

Um fluxo simples pode ser: create request -> se o valor estiver acima do limite, set status para needs_approval -> notificar gerente -> se aprovado, set para approved -> notificar solicitante -> se sem resposta em 24 horas, enviar lembrete.

Em uma ferramenta como AppMaster, isso mapeia bem para um Business Process que reage a mudanças de status e dispara email, SMS ou mensagens no Telegram.

O que deve ser código customizado

Provedores de pagamento têm casos de borda que nem sempre encaixam bem em regras ou passos drag-and-drop. Mantenha lógica específica do provedor em código customizado, como reembolsos parciais com taxas ou pagamentos multi-capture, reconciliação via webhooks (o provedor diz “paid” mas seu app diz “processing”), e tratamento de idempotência e retries quando o provedor dá timeout.

O importante é que o código customizado não invente seus próprios status. Ele lê o registro Refund, executa a ação contra o provedor e grava de volta o próximo status e valores confirmados para que o banco continue sendo o livro-razão em que todos confiam.

Próximos passos: faça a escolha valer

Uma boa decisão só ajuda se ela estiver verdadeira seis meses depois. O objetivo é tornar a escolha “onde deve morar essa lógica?” fácil de ver, fácil de testar e difícil de contornar acidentalmente.

Crie um mapa simples de lógica: uma lista curta das regras-chave e o lar que você escolheu para cada uma. Mantenha breve e atualize quando uma regra mudar. Inclua o nome da regra, onde ela vive (banco, workflow, código customizado), por que (uma frase), o que ela lê e grava, e quem aprova mudanças.

Escreva limites como não negociáveis que protejam seu sistema quando pessoas adicionarem features depois. Um formato útil é: “O banco garante X” e “Workflows fazem cumprir Y.” Por exemplo, o banco garante que um registro de refund não pode existir sem um order, enquanto o workflow faz cumprir que reembolsos acima de $500 exigem aprovação de gerente.

Planeje testes antes de mudar qualquer coisa. Você não precisa de um grande plano de testes, apenas alguns casos que você vai reexecutar sempre que a regra mudar:

• Caminho feliz (input esperado, resultado esperado)
• Caminho de falha (dados faltando, status inválido, pedido duplicado)
• Concorrência (duas pessoas disparando a mesma ação ao mesmo tempo)
• Segurança (um usuário tentando pular passos ou chamar um endpoint diretamente)

Defina propriedade e regras de revisão também. Decida quem pode editar procedures armazenadas, quem pode editar workflows e o que precisa de revisão por pares. É aí que muitos sistemas ou se mantêm saudáveis ou derivam para “ninguém sabe por que isso funciona”.

Se você quer workflows drag-and-drop sem abrir mão de estrutura de backend real, uma plataforma como AppMaster (appmaster.io) pode ser um meio prático: modele seus dados, expresse o processo no Business Process Editor e regenere e faça deploy conforme os requisitos mudam.

Escolha uma regra de alto impacto, mapeie-a, adicione limites e escreva três casos de teste. Esse hábito único previne a maior parte da proliferação de lógica.