Um campo como estado = "pendente" parece suficiente até que o processo acumule aprovações, exceções e ações que dependem de como chegou àquele ponto. Então surgem perguntas práticas: é possível cancelar depois de aprovar? Quem pode reabrir um caso? O que acontece se a mesma solicitação chegar duas vezes? Uma máquina de estados ajuda a responder a essas perguntas ao descrever não apenas o estado atual, mas também as mudanças permitidas e seus efeitos.
Nem todo fluxo precisa desse modelo. Em um processo curto e linear, um rótulo de estado e algumas regras simples podem ser mais fáceis de construir e manter. A decisão consiste em comparar a complexidade real do fluxo com o custo de explicitar suas regras, não em adotar um padrão de antemão.
Estado como rótulo e máquina de estados: o que muda
Armazenar um estado como rótulo representa uma condição atual: por exemplo, uma tarefa pode aparecer como “pendente” ou “concluída”. Por si só, esse rótulo não explica quais mudanças são válidas, que evento as provoca nem quais ações devem acompanhá-las. Essa lógica costuma ficar distribuída pela interface, pelo servidor e por diferentes condições no código.
Uma máquina de estados descreve o processo como um conjunto definido de estados e transições. Uma transição estabelece qual evento permite passar de um estado a outro e, quando necessário, quais condições devem ser atendidas ou quais ações são executadas. Portanto, o estado atual limita as evoluções possíveis.
A diferença não está na quantidade de rótulos em um banco de dados. Um campo de estado pode fazer parte de uma máquina explícita se o sistema validar as transições. E uma lista extensa de estados não constitui, por si só, um bom modelo se ninguém consegue explicar como se passa de um para outro.
Sinais de que vale a pena definir transições explícitas
O modelo começa a trazer valor quando as regras dependem da etapa do processo e os erros de transição têm consequências. Observe estes sinais:
- Ações permitidas diferentes: nem todos podem aprovar, editar ou cancelar em cada etapa, ou uma ação só fica disponível após uma validação.
- Caminhos alternativos: uma solicitação pode ser aprovada, rejeitada, devolvida para completar informações ou cancelada.
- Regras distribuídas: diferentes partes do aplicativo verificam de forma independente se uma operação é válida, com o risco de apresentarem contradições.
- Efeitos associados à mudança: uma transição precisa registrar uma decisão, avisar alguém ou iniciar outra tarefa. Convém distinguir esse efeito da simples mudança de rótulo.
- Repetições e concorrência: duas pessoas ou processos podem tentar alterar o mesmo caso, ou uma integração pode repetir um evento.
Um bom sinal para o diagnóstico é a equipe discutir com frequência se uma mudança “deveria ser permitida” em determinada etapa. Se a resposta depender do estado anterior, de quem age ou de um resultado de negócio, convém registrar a regra de forma explícita e centralizada.
Quando estados simples são suficientes
Um modelo simples costuma bastar quando o processo é linear, tem poucas transições e as exceções são raras ou fáceis de administrar. Por exemplo, uma tarefa interna que passa de “pendente” para “concluída” pode precisar apenas de um campo e de uma verificação clara, sobretudo se não houver aprovações, novas tentativas nem consequências externas.
O custo operacional também importa. Uma máquina de estados introduz conceitos, testes e manutenção. Se o fluxo não apresenta ambiguidades, esse custo pode superar o benefício. Não transforme cada mudança de tela, etapa da interface ou pequena variação em um estado de negócio: uma experiência visual nem sempre corresponde a uma etapa do processo.
Como critério prático, comece com a representação mais simples que permita aplicar as regras importantes. Se surgirem condições repetidas, transições implícitas ou incidentes causados por mudanças inválidas, reavalie o projeto. A evolução pode ser gradual: não é necessário redesenhar todo o processo para formalizar primeiro as transições de maior risco.
Critérios para tomar a decisão
Não existe um número universal de estados ou transições a partir do qual uma máquina se torna necessária. Avalie o comportamento e o impacto dos erros com perguntas concretas:
- Quantos caminhos reais existem? Conte os caminhos de negócio e suas ramificações, não apenas os rótulos. Vários caminhos com permissões ou resultados distintos costumam justificar um modelo explícito.
- O que acontece se alguém tentar uma transição inválida? Se o efeito for um inconveniente reversível, uma validação simples pode bastar. Se puder gerar uma decisão incorreta, trabalho duplicado ou uma ação difícil de reverter, defina controles mais claros.
- Pode haver mudanças simultâneas ou eventos repetidos? Se sim, estabeleça como verificar se o estado mudou desde o início da operação e como evitar que o processamento repetido do mesmo evento duplique efeitos.
- É necessário explicar o percurso? Se as equipes de suporte, auditoria ou operações precisam saber quem fez o quê, quando e por quê, separar o estado atual do histórico de eventos facilita reconstruir a evolução.
- As regras cabem em um lugar compreensível? Se exigem exceções encadeadas em vários componentes, o problema já não é apenas a quantidade de estados: é um sinal de que o fluxo não tem uma definição única.
Como nomear estados, eventos e exceções
Use termos que descrevam etapas reconhecíveis para o negócio. Um estado responde “em que situação está o caso?”; um evento responde “o que aconteceu para que ele mudasse?”. Por exemplo, “em análise” pode ser um estado e “análise aprovada”, um evento. Evite tratar os dois conceitos como se fossem intercambiáveis.
Separe também a etapa do resultado quando forem dimensões distintas. “Encerrada” descreve uma etapa final, enquanto “aprovada” ou “rejeitada” descreve um resultado. Se esses conceitos forem misturados, podem surgir estados combinados, como “encerrada e rejeitada”, que multiplicam as variações e dificultam o entendimento das regras.
Identifique quais estados são terminais, isto é, aqueles em que o processo normalmente termina. Defina separadamente se é possível cancelar ou reabrir um caso e quem pode fazê-lo. Um estado terminal não precisa impedir toda ação administrativa, mas essa exceção deve ser delimitada e não pode se transformar em um atalho para contornar as regras.
Para novas tentativas, evite criar um estado para cada tentativa se o caso continua na mesma etapa. Mantenha o estado adequado e registre a tentativa no histórico ou como um dado separado. Faça o mesmo com falhas e exceções: crie um estado distinto apenas se elas alterarem de forma relevante o que o negócio pode fazer em seguida.
Exemplo hipotético: uma solicitação em análise
Imagine uma solicitação que é recebida, analisada e, por fim, aprovada ou rejeitada. Na versão mais simples, os estados poderiam ser “recebida”, “em análise” e “resolvida”, com um resultado associado. Se a equipe precisar pedir informações adicionais, o fluxo deverá representar essa pausa e definir qual evento permite voltar à análise quando a resposta chegar.
Uma transição pode especificar que somente uma pessoa autorizada pode aprovar ou rejeitar uma solicitação “em análise”. Se ela for rejeitada, o caso fica resolvido com o resultado “rejeitado”; se faltarem informações, passa para “aguardando informações”. A máquina não exige uma plataforma especial: basta que o sistema valide essas mudanças de forma consistente e registre os dados necessários.
Este exemplo é hipotético; os nomes e as regras devem ser ajustados ao processo real. Se pedir informações não mudar as ações disponíveis nem exigir acompanhamento, pode bastar registrar uma observação. O modelo deve refletir diferenças operacionais, não antecipar todas as possibilidades imagináveis.
Erros frequentes e lista de verificação
Um modelo pode se tornar mais difícil do que o processo se criar estados para cada detalhe, misturar permissões com etapas ou não definir o que acontece com os casos antigos quando as regras mudam. Também é um erro desenhar as transições e deixar que o código as ignore: a regra precisa ser aplicada onde a mudança é aceita.
Antes de escolher ou revisar a abordagem, verifique o seguinte:
- Cada estado representa uma situação que o negócio consegue explicar?
- Os eventos descrevem fatos e as transições especificam quais mudanças são permitidas?
- Os caminhos alternativos, cancelamentos e reaberturas estão claros?
- Operações inválidas são rejeitadas e eventos repetidos ou mudanças simultâneas são controlados?
- O histórico é registrado quando é necessário reconstruir decisões?
- Há estados que podem ser combinados sem perder regras ou informações relevantes?
Escolha uma máquina de estados quando ela tornar visíveis e aplicáveis regras que, de outro modo, ficariam dispersas, e quando o custo de uma transição incorreta justificar esse controle. Se o processo for linear e previsível, comece com estados simples. Reavalie a decisão quando mudarem os caminhos, as exceções ou as consequências: o melhor modelo é o mais simples que representa fielmente como o trabalho evolui.