Lenguaje ubicuo
Una reunión sobre «el cliente»
En BCPS Bank se convoca una reunión para diseñar «la tabla de clientes, única para todo el banco». Vienen cinco equipos. Todos están de acuerdo en que el cliente es lo más importante. Ninguno está hablando de lo mismo.
Para Clientes, un cliente es una persona que ha pasado la verificación de identidad (el KYC). Para Cuentas, es el titular de una cuenta, y una cuenta puede tener dos. Para Tarjetas, es quien lleva la tarjeta en la cartera, que a veces es la hija de 16 años de una clienta. Para Reporting, es la contraparte de un informe, que puede ser un comercio o el banco de Luis.
La reunión acaba con una tabla de 20 columnas y la sensación de que alguien va a pasarlo mal. Este episodio va de por qué, y de lo que hace DDD en su lugar.
Cuatro peticiones
Los dos paneles empiezan con la misma ficha de Cliente, la de Clientes. Cada contexto va pidiendo lo que necesita para su trabajo. A la izquierda, todo se añade a esa única ficha. A la derecha, cada contexto tiene la suya, y se unen por id cuando hace falta. Cada petición llega con un caso real: mira qué pasa con él en cada modelo.
Pulsa Siguiente petición, o elige una.
Qué ha pasado
Cuatro choques
Cada petición es razonable por sí sola. El problema es que cada una trae su propio significado de «cliente», y en la ficha única no caben todos a la vez:
- La cuenta conjunta.probar en el laboratorio Cuentas pide un saldo. Pero «el saldo del cliente» no tiene sentido cuando Ana es titular de dos cuentas y una de ellas la comparte con Luis. El saldo es de una cuenta, no de una persona.
- La hija de Ana.probar en el laboratorio Tiene 16 años y una tarjeta asociada a la cuenta de su madre. No ha pasado el KYC, porque no es clienta del banco: es portadora de una tarjeta. En la ficha única, la regla «todo cliente ha pasado el KYC» se rompe. O se relaja para todos (y deja de proteger lo que protegía) o la hija se queda sin tarjeta.
- La contraparte.probar en el laboratorio Para Reporting, el «cliente» de un informe puede ser un comercio o el banco de Luis, que no son personas. La ficha acaba con
esPersona, un DNI opcional, un NIF opcional y una razón social opcional. Medio modelo vacío en cada fila, y nadie sabe qué combinaciones son válidas. - El saldo.probar en el laboratorio Ana ve 100 € en la app, paga 90 € con tarjeta y se deniega: tenía 30 € retenidos de la gasolinera. Un solo campo
saldoobliga a elegir entre el contable (lo que dice el extracto) y el disponible (lo que se puede gastar), y cualquiera de las dos respuestas deja a alguien mal.
El modelo único no falla por estar mal hecho. Falla porque intenta ser verdad en cuatro sitios a la vez, y las verdades no coinciden: ni siquiera en quién abarcan.
El lenguaje ubicuo
DDD propone lo contrario: dentro de cada parte del sistema, cada palabra significa una sola cosa, y esa cosa es la misma en la conversación, en la documentación y en el código. Eso es el lenguaje ubicuo: el vocabulario compartido entre quien conoce el negocio y quien escribe el software, sin traducciones por el camino.
La condición es «dentro de cada parte». En todo el banco no puede haber un lenguaje ubicuo, porque «cliente» no significa lo mismo en todo el banco. Así que se aceptan varios lenguajes, cada uno con su frontera, y se traduce en la frontera:
| Palabra | Clientes | Cuentas | Tarjetas | Reporting |
|---|---|---|---|---|
| Cliente | Persona verificada con documentación | Titular (o cotitular) de una cuenta | Portador de una tarjeta | Contraparte en un informe |
| Saldo | — | Contable (suma de movimientos) y disponible (contable − retenciones) | Crédito disponible | Saldo a fecha de cierre |
| Cuenta | Relación comercial con el banco | Libro de movimientos con IBAN | Cuenta asociada de la que se carga | Cuenta contable del plan de cuentas |
En el panel de la derecha, cada ficha usa las palabras de su contexto: Cuentas no tiene «clientes», tiene titulares, referenciados por el id de Clientes. Tarjetas tiene portadores, que pueden no ser clientes. Y la regla del KYC sigue intacta donde importa. A esa frontera, dentro de la cual un modelo y su lenguaje son coherentes, DDD la llama bounded context.
El convenio de la serie de eventos era lenguaje ubicuo
Si leíste la serie de eventos, ya has usado un lenguaje ubicuo sin llamarlo así. En banca, «transacción» significa tres cosas: un cargo o abono en una cuenta, una operación del cliente (una transferencia) y una transacción de base de datos. Para no liarse, la serie fijó un convenio:
| Término | Significa |
|---|---|
| Movimiento | Un cargo o abono en una cuenta |
| Operación | Una acción de negocio del cliente, que puede generar varios movimientos |
| Transacción | Solo la de base de datos (ACID) |
Ese convenio es exactamente lo que DDD pide: decidir qué significa cada palabra, escribirlo y usarlo igual en el código. MovimientoRegistrado se llama así, y no TransaccionCreada, por eso.
Criterio
Un modelo compartido no es siempre un error. Es lo correcto cuando un equipo pequeño trabaja en un dominio pequeño: si «cliente» significa lo mismo para todos los que lo usan, separarlo solo añade traducciones. Las señales de que un modelo se ha quedado pequeño para su nombre son reconocibles:
| Señal | En BCPS Bank |
|---|---|
| Campos que solo usa una parte del sistema y están vacíos en el resto | razonSocial, tutor |
| Banderas que dicen «este no es de los normales» | esPersona, esPortador |
| Reglas que valen para unos casos y estorban en otros | El KYC y la hija de Ana |
| Campos cuyo significado depende de quién pregunte | saldo |
| Reuniones en las que dos equipos usan la misma palabra y discuten sin entenderse | La de la tabla de clientes |
Cuando aparecen, la pregunta no es «¿qué columnas le faltan?», sino «¿cuántos significados tiene esta palabra, y dónde cambia?». Ahí es donde hay que cortar.
En el mundo real
El término ubiquitous language viene del libro de Eric Evans, Domain-Driven Design (2003), igual que bounded context. Vaughn Vernon lo desarrolló en Implementing Domain-Driven Design (2013), y Vlad Khononov en Learning Domain-Driven Design (2021) lo explica con ejemplos más cercanos a sistemas actuales.
La «tabla de clientes única» tiene nombre en la industria: los proyectos de master data management y de «vista 360 del cliente». No son un error en sí (a un banco le interesa saber todo lo que tiene con una persona), pero suelen funcionar mejor como un contexto más, que lee de los demás y los relaciona por id, que como un modelo central que todos tienen que usar.
En la práctica, el lenguaje ubicuo se mantiene con un glosario vivo por contexto (como las tablas de este episodio), con nombres de clases y eventos que salen de él, y revisándolo cuando alguien del negocio usa una palabra que el código no tiene.
Siguiente episodio
Sabemos que hay que cortar donde cambia el significado de las palabras. Pero ¿cómo se encuentran esos sitios sin una reunión de tres semanas? Con una pared, muchos post-its naranjas y a la gente que conoce el negocio en la misma sala.
Siguiente · Episodio 2 Event Storming y bounded contexts Un día de Ana en eventos, ordenado en una pared. De ahí sale el mapa de los ocho contextos de BCPS Bank.