System Design
Diagramas de estados
Explica cómo representar estados, eventos, condiciones, transiciones y estados terminales mediante diagramas de estados aplicados al comportamiento del dominio.
- Última actualización
- Actualizada
- Nivel
- Aplicación
System Design
Explica cómo representar estados, eventos, condiciones, transiciones y estados terminales mediante diagramas de estados aplicados al comportamiento del dominio.
Un diagrama de estados hace visible el ciclo de vida válido de una entidad: estados, eventos, guards y efectos. No es solo una lista de etiquetas; es una representación de las reglas que permiten o impiden cada cambio.
State Diagram responde:
¿en qué situaciones puede estar la entidad?
¿qué evento intenta cambiarla?
¿qué condición permite el cambio?
¿qué efecto produce?Es especialmente útil en pedidos, pagos, créditos, suscripciones, transferencias y aprobaciones.
Una tabla con status no comunica por sí sola:
El diagrama permite revisar el modelo con negocio y desarrollo antes de implementar validaciones dispersas.
Punto desde el cual nace la entidad o el workflow.
Condición estable y significativa.
Cambio dirigido entre estados.
Hecho o comando que dispara la transición.
Condición entre corchetes que debe cumplirse.
Efecto asociado, expresado después de / en notaciones comunes.
Indica final del ciclo modelado, no necesariamente eliminación de la entidad.
Contiene subestados y permite modelar jerarquía sin expandir todo en un plano.
Pseudoestado que permite regresar al último subestado, útil en ciertos workflows; no debe usarse sin necesidad real.
stateDiagram-v2
[*] --> Draft
Draft --> Confirmed : confirm [items > 0 && stockReserved]
Confirmed --> Preparing : startPreparation
Preparing --> Ready : completePreparation
Ready --> Dispatched : dispatch [deliveryAssigned]
Dispatched --> Delivered : confirmDelivery
Draft --> Cancelled : cancel
Confirmed --> Cancelled : cancel [beforePreparation] / releaseStock
Preparing --> CancellationPending : cancel [requiresApproval]
CancellationPending --> Cancelled : approve / compensate
CancellationPending --> Preparing : reject
Delivered --> [*]
Cancelled --> [*]confirm solo funciona con items y reserva válida.confirmed libera stock.Delivered y Cancelled cierran el ciclo del pedido, aunque después pueda comenzar devolución como proceso separado.El diagrama comunica estructura; la tabla conserva detalle verificable.
| Desde | Evento | Guard | Hacia | Efecto |
|---|---|---|---|---|
| Draft | confirm | items y reserva | Confirmed | capturar precios |
| Confirmed | cancel | antes de preparación | Cancelled | liberar stock |
| Preparing | cancel | requiere aprobación | CancellationPending | registrar solicitud |
Mantén ambos enlazados; no intentes meter toda la explicación dentro de flechas.
El guard expresa una condición de transición del dominio. Puede necesitar datos externos o cálculos, pero no debe ser una expresión técnica ilegible.
[stockReserved]es más comunicativo que una consulta SQL completa.
La implementación debe garantizar que la condición y el cambio no sufran carreras.
Una transición puede producir:
Si el efecto es crítico para la invariante, coordínalo atómicamente o modela un estado pendiente.
Ejemplo: Active contiene Trial, Paid y GracePeriod. Ayudan cuando los subestados comparten transiciones generales.
Active → Suspendedpuede aplicar desde cualquier subestado. Úsalos cuando reducen duplicación semántica, no para crear jerarquías visuales complejas.
Algunas dimensiones evolucionan en paralelo:
Order lifecycle
Payment lifecycle
Delivery lifecycleUn diagrama gigante con todas las combinaciones explota. Crea máquinas separadas y documenta invariantes entre ellas, por ejemplo: Delivered requiere delivery completado, pero no necesariamente refund inexistente.
Para eventos externos define autenticación, duplicados, orden y vigencia.
Un timer también dispara transición:
Reserved --> Expired : after 15m / releaseStockAclara:
Una transición puede ocurrir al entrar en estado o al cumplirse condición. Evita cadenas automáticas difíciles de observar; cada cambio significativo debería tener evidencia y control de loops.
El diagrama define que solo una transición válida ocurre desde una versión concreta. La implementación puede usar:
UPDATE ... WHERE id = ? AND status = 'confirmed' AND version = ?Si afecta una fila, ganó; si no, el estado cambió. El diagrama no sustituye esta protección, pero establece qué se debe proteger.
Un evento repetido puede:
Debe evitar repetir efectos. Documenta la política en la transición o contrato.
Puede ser terminal o error de diseño. Nómbralo claramente.
Elimina o añade transición; código muerto conceptual también confunde.
Dos transiciones podrían ser válidas. Define prioridad o guards mutuamente exclusivas.
Puede ser automática, pero explica qué la activa.
Usa estado pendiente, outbox o compensación.
Define mapping y estados desconocidos.
No reutilices transición inversa si el negocio realmente crea un nuevo ciclo.
Distingue reintentable, terminal y manual.
Se centra en una entidad y transiciones válidas.
Se centra en el camino del trabajo.
Se centra en mensajes entre participantes.
Ejemplo: cancelación puede tener un State Diagram del pedido, un Activity del proceso de aprobación y un Sequence de llamadas técnicas.
Opciones:
Elige según cantidad de estados, persistencia, timers, intervención y operación. No introduzcas engine para tres estados simples.
ValidatePayment es acción; PaymentPending es estado.
El diagrama permite cambios imposibles.
La transición parece inocua, pero altera inventario o dinero.
Produce combinaciones inmanejables.
ModalOpen no pertenece al ciclo de negocio salvo que estudies UI state.
El dibujo no contiene ownership, errores o auditoría.
“Puede volver” suele ocultar reglas distintas.
Cuando una entidad tiene comportamiento dependiente del estado, varios eventos o procesos largos. Para un booleano realmente binario y sin transiciones complejas, puede ser innecesario.
Modelado del dominio identifica entidades, valores, invariantes y fronteras que sostienen estos comportamientos.