El cheque es una máquina de estados

La mayoría de los sistemas modela un cheque como una fila con un campo estado. Funciona hasta que alguien necesita revertir un estado — y ahí descubrís que el modelo nunca fue el campo.

Un cheque recibido de un cliente atraviesa estados: recibido, depositado, acreditado, rechazado, endosado a un proveedor, anulado. Cada transición tiene precondiciones, efectos sobre el saldo de alguien, y una reversa que no siempre está permitida.

Lo que la columna de estado no puede expresar

Qué transiciones son legales. De acreditado no se vuelve a recibido. Desde endosado no se puede depositar. Un estado de texto libre deja que cualquier código escriba cualquier valor, así que las reglas viven desparramadas entre quienes las recuerdan.

Qué le hace cada transición al dinero. Depositar mueve un importe a una cuenta. El rechazo lo revierte y suele agregar una comisión. Endosar transfiere el instrumento a la cuenta de un proveedor. La transición es la operación, no una actualización de metadata.

Qué pasó antes. “Anulado” no te dice si antes estuvo acreditado. Necesitás la historia, con fechas y quién lo hizo — porque alguien va a preguntar meses después.

Modelar transiciones cambia la forma del código

En vez de un setEstado llamado desde quince lugares, hay operaciones con nombre — depositar, rechazar, endosar — cada una validando sus precondiciones y escribiendo sus propios movimientos y su entrada de historial. La transición inválida se vuelve imposible, no meramente improbable.

El principio general

Si el campo se llama estado y el objeto tiene un ciclo de vida, el campo es un síntoma. Modelá las transiciones, y los estados salen solos de ellas.

Así están modelados los cheques en YSY Empresa: cada movimiento del circuito de valores es una operación auditada, no un update.