Un sistema bancario en UML

Casi todos los ejemplos bancarios de internet le dan a Account un atributo balance y un par de métodos que le suman y le restan. Es lo primero que hay que borrar, porque ningún libro mayor que deba ser auditable funciona así.

Un saldo almacenado es una segunda copia de un hecho que los asientos ya contienen. Dos copias de un hecho pueden discrepar, y cuando lo hacen - un fallo parcial, un mensaje reintentado, una migración - no hay forma de saber cuál es la correcta, porque el saldo no lleva historia contra la que comprobarlo. Derivarlo, como balance() en la figura de arriba, hace imposible la discrepancia por construcción.

La composición a la derecha de la figura de cabecera es la segunda decisión estructural. Una Transaction está compuesta de exactamente dos asientos - la multiplicidad dice 2, no 0..* - y por convención suman cero: el dinero sale de una cuenta y llega a otra.

Dibujar una asociación de Account directamente a Account, que es el primer intento obvio, pierde las dos mitades de eso. Pierde la atomicidad, porque dos flechas pueden existir de forma independiente y una transferencia no puede ocurrir a medias. Y pierde la referencia: una transacción es algo por lo que los clientes preguntan por número, que reclaman y que revierten, lo que significa que es una entidad y no una línea entre otras dos.

El rombo relleno dice entonces que los asientos mueren con la transacción. Eso es correcto y es además una restricción sobre el código: no puedes borrar media transferencia, y una reversión es una nueva transacción en vez de una edición de la vieja. La guía del diagrama de clases tiene las reglas completas de cuándo un rombo va relleno.

Una máquina de estados se gana su sitio siempre que un objeto tiene un ciclo de vida del que dependen reglas, y el dinero moviéndose es el arquetipo. El valor no son las cuatro cajas, que adivinaría cualquiera: son las transiciones que faltan.

Settled no tiene transición de salida. Eso dice que una transferencia liquidada es firme y que una reversión es otra transacción y no un cambio de estado, que es la misma afirmación que hacía la composición en el modelo de dominio. Rejected tampoco tiene: una aprobación tras un rechazo inicia una transferencia nueva. Las guardas hacen explícito el resto: reject [limit]nombra el porqué, y un diagrama que dice solo "reject" le deja la razón al lector.

Para el mismo tratamiento en otro dominio, mira la arquitectura de comercio electrónico, modelada. Para la mitad de modelado de datos de un libro mayor - claves, cardinalidad y el esquema de debajo - mira los diagramas ER.