Un campo como estado = "pendiente" parece suficiente hasta que el proceso acumula aprobaciones, excepciones y acciones que dependen de cómo llegó a ese punto. Entonces surgen preguntas prácticas: ¿se puede cancelar después de aprobar?, ¿quién puede reabrir un caso?, ¿qué ocurre si llega dos veces la misma solicitud? Una máquina de estados ayuda a responderlas al describir no solo el estado actual, sino también los cambios permitidos y sus efectos.
No todo flujo necesita ese modelo. En un proceso breve y lineal, una etiqueta de estado y unas reglas sencillas pueden ser más fáciles de construir y mantener. La decisión consiste en comparar la complejidad real del flujo con el coste de hacer explícitas sus reglas, no en adoptar un patrón por anticipado.
Estado como etiqueta y máquina de estados: qué cambia
Guardar un estado como etiqueta representa una condición actual: por ejemplo, una tarea puede figurar como “pendiente” o “completada”. Por sí sola, esa etiqueta no explica qué cambios son válidos, qué evento los provoca ni qué acciones deben acompañarlos. Esa lógica suele quedar repartida entre la interfaz, el servidor y distintas condiciones del código.
Una máquina de estados describe el proceso como un conjunto definido de estados y transiciones. Una transición establece qué evento permite pasar de un estado a otro y, cuando corresponde, qué condiciones deben cumplirse o qué acciones se ejecutan. El estado actual, por tanto, limita las evoluciones posibles.
La diferencia no está en cuántas etiquetas tiene una base de datos. Un campo de estado puede formar parte de una máquina explícita si el sistema valida las transiciones. Y una lista extensa de estados no constituye por sí misma un buen modelo si nadie puede explicar cómo se pasa entre ellos.
Señales de que conviene definir transiciones explícitas
El modelo empieza a aportar valor cuando las reglas dependen del punto del proceso y los errores de transición tienen consecuencias. Presta atención a estas señales:
- Acciones permitidas diferentes: no todos pueden aprobar, editar o cancelar en cada etapa, o una acción solo está disponible después de una validación.
- Caminos alternativos: una solicitud puede aprobarse, rechazarse, devolverse para completar información o cancelarse.
- Reglas distribuidas: distintas partes de la aplicación comprueban de forma independiente si una operación es válida, con riesgo de que se contradigan.
- Efectos asociados al cambio: una transición debe registrar una decisión, avisar a alguien o iniciar otra tarea. Conviene distinguir ese efecto del simple cambio de etiqueta.
- Reintentos y concurrencia: dos personas o procesos podrían intentar modificar el mismo caso, o una integración podría repetir un evento.
Una buena señal diagnóstica es que el equipo discute con frecuencia si un cambio “debería permitirse” en una etapa concreta. Si esa respuesta depende del estado previo, de quién actúa o de un resultado de negocio, conviene registrar la regla de forma explícita y centralizada.
Cuándo bastan estados simples
Un modelo sencillo suele ser suficiente cuando el proceso es lineal, tiene pocas transiciones y las excepciones son raras o fáciles de gestionar. Por ejemplo, una tarea interna que pasa de “pendiente” a “completada” puede necesitar únicamente un campo y una comprobación clara, sobre todo si no hay aprobaciones, reintentos ni consecuencias externas.
También importa el coste operativo. Una máquina de estados introduce conceptos, pruebas y mantenimiento. Si el flujo no presenta ambigüedades, ese coste puede superar el beneficio. No conviertas cada cambio de pantalla, paso de interfaz o variación menor en un estado de negocio: una experiencia visual no siempre corresponde a una etapa del proceso.
Como criterio práctico, empieza con la representación más simple que permita hacer cumplir las reglas importantes. Si aparecen condiciones repetidas, transiciones implícitas o incidencias por cambios inválidos, revisa el diseño. La evolución puede ser gradual: no es necesario rediseñar todo el proceso para formalizar primero las transiciones de mayor riesgo.
Criterios para tomar la decisión
No existe un número universal de estados o transiciones a partir del cual una máquina resulte necesaria. Evalúa el comportamiento y el impacto de los errores con preguntas concretas:
- ¿Cuántas rutas reales existen? Cuenta los caminos de negocio y sus bifurcaciones, no solo las etiquetas. Varias rutas con permisos o resultados distintos suelen justificar un modelo explícito.
- ¿Qué pasa si alguien intenta una transición inválida? Si el efecto es una molestia reversible, una validación simple puede bastar. Si puede generar una decisión incorrecta, trabajo duplicado o una acción difícil de revertir, define controles más claros.
- ¿Puede haber cambios simultáneos o eventos repetidos? Si la respuesta es sí, establece cómo comprobar que el estado no cambió desde que se inició la operación y cómo evitar que procesar dos veces el mismo evento duplique efectos.
- ¿Hace falta explicar el recorrido? Si soporte, auditoría u operaciones necesitan saber quién hizo qué, cuándo y por qué, separar el estado actual del historial de eventos facilita reconstruir la evolución.
- ¿Las reglas caben en un lugar comprensible? Si requieren excepciones encadenadas en varios componentes, el problema ya no es solo de cantidad de estados: es una señal de que el flujo carece de una definición única.
Cómo nombrar estados, eventos y excepciones
Usa términos que describan etapas reconocibles para el negocio. Un estado responde “¿en qué situación está el caso?”; un evento responde “¿qué ocurrió para cambiarlo?”. Por ejemplo, “en revisión” puede ser un estado y “revisión aprobada”, un evento. Evita usar ambos conceptos como si fueran intercambiables.
Separa también la etapa del resultado cuando sean dimensiones distintas. “Cerrada” describe una etapa final, mientras que “aprobada” o “rechazada” describe un resultado. Si se mezclan, pueden aparecer estados combinados como “cerrada y rechazada”, que multiplican las variantes y hacen más difícil razonar sobre las reglas.
Marca qué estados son terminales, es decir, en cuáles el proceso termina normalmente. Define por separado si una cancelación o reapertura es posible y quién puede hacerla. Un estado terminal no tiene por qué impedir toda acción administrativa, pero esa excepción debe estar delimitada y no convertirse en una puerta trasera para saltarse las reglas.
Para reintentos, evita crear un estado nuevo por cada intento si el caso sigue en la misma etapa. Conserva el estado adecuado y registra el intento como parte del historial o como dato separado. Haz lo mismo con fallos y excepciones: crea un estado distinto solo si cambia de forma relevante lo que el negocio puede hacer después.
Ejemplo hipotético: una solicitud con revisión
Imagina una solicitud que se recibe, se revisa y termina aprobada o rechazada. En la versión más sencilla, los estados podrían ser “recibida”, “en revisión” y “resuelta”, con un resultado asociado. Si el equipo debe pedir información adicional, el flujo necesita representar esa pausa y definir qué evento permite volver a revisión cuando llega la respuesta.
Una transición puede especificar que solo una persona autorizada apruebe o rechace desde “en revisión”. Si se rechaza, el caso queda resuelto con resultado “rechazado”; si falta información, pasa a “pendiente de información”. La máquina no exige una plataforma especial: basta con que el sistema valide de manera consistente esos cambios y registre los datos necesarios.
Este ejemplo es hipotético; los nombres y reglas deben ajustarse al proceso real. Si pedir información no cambia las acciones disponibles ni requiere seguimiento, puede bastar con registrar una nota. El modelo debe reflejar diferencias operativas, no anticipar todas las posibilidades imaginables.
Errores frecuentes y lista de comprobación
Un modelo puede volverse más difícil que el proceso si crea estados para cada detalle, mezcla permisos con etapas o no define qué sucede con los casos antiguos cuando cambian las reglas. También es un error modelar transiciones en un diagrama y dejar que el código las ignore: la regla debe aplicarse allí donde se acepta el cambio.
Antes de elegir o revisar el enfoque, comprueba lo siguiente:
- ¿Cada estado representa una situación que el negocio puede explicar?
- ¿Los eventos describen hechos y las transiciones especifican qué cambios permiten?
- ¿Están claros los caminos alternativos, las cancelaciones y las reaperturas?
- ¿Se rechazan operaciones inválidas y se controlan eventos repetidos o cambios simultáneos?
- ¿Se registra el historial cuando es necesario reconstruir decisiones?
- ¿Hay estados que pueden fusionarse sin perder reglas o información relevante?
Elige una máquina de estados cuando haga visibles y aplicables reglas que de otro modo quedarían dispersas, y cuando el coste de una transición incorrecta justifique ese control. Si el proceso es lineal y predecible, empieza con estados simples. Revisa la decisión cuando cambien las rutas, las excepciones o las consecuencias: el mejor modelo es el más sencillo que representa fielmente cómo evoluciona el trabajo.