4. Lenguaje ubicuo: construir un vocabulario común con los expertos del negocio
4.1 Introducción
El lenguaje ubicuo es un vocabulario compartido por todas las personas que participan en el desarrollo de un sistema: expertos del negocio, usuarios, analistas, desarrolladores, testers, diseñadores y responsables del producto. Su objetivo es que los conceptos importantes del dominio se nombren de la misma manera y con el mismo significado en conversaciones, requerimientos, casos de uso, modelos, pruebas, documentación y código.
La palabra "ubicuo" significa que está presente en todas partes. En este contexto, indica que el lenguaje del dominio no debería quedar limitado a una reunión o a un documento aislado. Debe aparecer de forma consistente en todo el trabajo del proyecto.
4.2 Por qué el lenguaje es tan importante
Muchos errores de software empiezan con una palabra mal entendida. Si una persona dice "cliente" y otra interpreta "usuario", o si alguien habla de "pedido" mientras otra persona piensa en "orden de compra", el equipo puede construir funcionalidades correctas desde lo técnico pero equivocadas desde el negocio.
El modelado de dominio depende de nombres precisos. Un concepto mal nombrado puede generar reglas mal ubicadas, casos de uso ambiguos, pruebas incompletas y código difícil de mantener. Por eso, antes de discutir detalles técnicos, conviene asegurarse de que el equipo entiende qué significa cada término central.
4.3 Representación del lenguaje ubicuo
4.4 Qué incluye el lenguaje ubicuo
El lenguaje ubicuo incluye todos los términos que tienen significado para el dominio. No se limita a nombres de entidades. También puede incluir estados, eventos, reglas, acciones, roles, documentos, políticas y expresiones usadas por los expertos del negocio.
En un sistema de turnos, el lenguaje ubicuo puede incluir términos como Paciente, Profesional, Especialidad, Agenda, Turno, Reserva, Cancelación, Ausencia, Sobreturno, Franja horaria, Confirmación y Disponibilidad. Cada uno de esos términos debe tener un significado claro.
También puede incluir frases de negocio, por ejemplo: "un turno confirmado", "una agenda bloqueada", "una cancelación fuera de término" o "un paciente con inasistencias reiteradas". Estas expresiones suelen esconder reglas importantes.
4.5 El rol de los expertos del negocio
Los expertos del negocio son fundamentales para construir el lenguaje ubicuo. Ellos conocen cómo se trabaja realmente, qué palabras se usan, qué diferencias existen entre términos parecidos y qué reglas no siempre están escritas. Sin su participación, el equipo técnico puede inventar nombres que parecen razonables pero no coinciden con la realidad del dominio.
El analista o modelador no debe imponer vocabulario técnico cuando el negocio ya tiene una forma clara de nombrar sus conceptos. Su tarea es escuchar, preguntar, detectar ambigüedades y ayudar a ordenar el lenguaje para que sea útil en el sistema.
4.6 Detectar palabras ambiguas
Una palabra es ambigua cuando puede interpretarse de más de una manera. En proyectos de software, esto ocurre con frecuencia porque distintas áreas del negocio usan la misma palabra con significados diferentes, o porque varias palabras se usan para referirse a algo que parece similar pero no lo es.
Por ejemplo, "usuario" puede significar una persona que inicia sesión, un cliente registrado, un empleado interno o cualquier persona que usa el sistema. "Reserva" puede significar una solicitud pendiente, una confirmación definitiva o un bloqueo temporal de disponibilidad. "Cancelado" puede significar anulado por el usuario, vencido por falta de pago o eliminado por administración.
Cuando aparece una palabra ambigua, no conviene resolverla solo por intuición. Hay que preguntar, buscar ejemplos y validar con expertos.
4.7 Sinónimos y términos duplicados
Otro problema habitual es tener varios nombres para el mismo concepto. Un equipo puede hablar de "cliente", "comprador", "usuario final" y "persona registrada" como si fueran equivalentes. Si realmente son lo mismo, conviene elegir un término principal. Si no son lo mismo, el modelo debe explicar la diferencia.
Los sinónimos innecesarios aumentan el costo de comunicación. También pueden aparecer en el código, en la base de datos y en la documentación, haciendo más difícil saber si dos elementos representan lo mismo o cosas distintas.
4.8 Ejemplo: paciente, usuario y persona
En un sistema de turnos médicos pueden aparecer los términos Persona, Usuario y Paciente. A primera vista parecen similares, pero pueden tener significados distintos. Persona puede representar datos personales básicos. Usuario puede ser quien tiene cuenta para iniciar sesión. Paciente puede ser quien recibe atención médica.
Una misma persona podría ser paciente sin tener usuario en el sistema, por ejemplo si la registra un administrativo. También podría existir un usuario administrativo que no es paciente. Si el equipo no aclara estas diferencias, puede diseñar mal permisos, datos obligatorios, reglas de reserva y pantallas de gestión.
El lenguaje ubicuo ayuda a separar estos conceptos cuando corresponde y a usar cada palabra con precisión.
4.9 Crear un glosario vivo
Una práctica útil es mantener un glosario del dominio. No debe ser un documento pesado ni burocrático. Debe ser una referencia viva, actualizada a medida que el equipo aprende. Cada entrada puede incluir el nombre del concepto, una definición breve, ejemplos, reglas asociadas y términos que no deben confundirse.
Por ejemplo:
El glosario ayuda a incorporar nuevos integrantes, revisar requerimientos, escribir casos de uso, definir pruebas y evitar discusiones repetidas sobre el significado de los términos.
4.10 El lenguaje ubicuo en los modelos
El modelo de dominio debe usar los mismos nombres que el lenguaje ubicuo. Si el negocio habla de Turno, Agenda y Profesional, el modelo no debería reemplazarlos por nombres técnicos como RegistroHorario, TablaAgenda o EntidadPrestador sin una razón justificada.
Los diagramas UML conceptuales también deben respetar este vocabulario. Las clases conceptuales, asociaciones, roles y estados deberían poder ser leídos por expertos del dominio. Si el diagrama está lleno de nombres técnicos, pierde valor como herramienta de validación.
4.11 El lenguaje ubicuo en las pruebas
Las pruebas también se benefician del lenguaje ubicuo. Un caso de prueba llamado "no permitir reservar un turno ocupado" es más claro que uno llamado "validar error en endpoint de alta". El primer nombre expresa una regla del negocio; el segundo describe un detalle técnico.
Esto no significa que no existan pruebas técnicas. Significa que las pruebas que verifican reglas del dominio deberían hablar en términos del dominio. Así es más fácil revisar si el sistema cumple lo que el negocio espera.
4.12 El lenguaje ubicuo en el código
Cuando el proyecto avanza hacia el diseño y la implementación, el lenguaje ubicuo puede influir en nombres de clases, métodos, módulos, eventos, pruebas y documentación técnica. Esto reduce la distancia entre conversación y código.
Si el negocio habla de Cancelación fuera de término, el código puede reflejar esa regla con nombres cercanos al dominio. Si el negocio habla de Turno confirmado, no conviene que el código use un estado llamado "OK" o "flag2". Los nombres técnicos pobres ocultan conocimiento y dificultan el mantenimiento.
El objetivo no es que todo el código sea entendido por usuarios finales, sino que el conocimiento del dominio no se pierda al pasar a la implementación.
4.13 Cómo construir el lenguaje ubicuo
El lenguaje ubicuo se construye con práctica continua. Algunas acciones útiles son:
- Escuchar las palabras que usan los expertos del negocio.
- Preguntar el significado exacto de términos importantes.
- Pedir ejemplos y contraejemplos para validar definiciones.
- Registrar términos relevantes en un glosario vivo.
- Unificar sinónimos cuando no aportan diferencia real.
- Separar conceptos que parecen iguales pero tienen reglas distintas.
- Usar el vocabulario acordado en requerimientos, casos de uso, modelos, pruebas y código.
4.14 Preguntas para validar términos
Estas preguntas ayudan a revisar si un término está bien definido:
- ¿Quién usa esta palabra en el negocio?
- ¿Qué significa exactamente?
- ¿Tiene el mismo significado para todas las áreas?
- ¿Existe otro término que se use como sinónimo?
- ¿Hay situaciones donde este concepto cambia de estado?
- ¿Qué reglas dependen de este concepto?
- ¿Podemos mostrar ejemplos concretos donde aparezca?
4.15 Errores frecuentes
Al construir un lenguaje ubicuo, suelen aparecer errores como los siguientes:
- Adoptar nombres técnicos antes de entender el vocabulario del negocio.
- Usar una misma palabra para conceptos distintos.
- Usar muchas palabras distintas para un mismo concepto.
- No registrar decisiones de vocabulario importantes.
- Crear un glosario inicial y abandonarlo sin actualizar.
- No validar definiciones con ejemplos reales.
- Permitir que el código use nombres que contradicen el modelo de dominio.
4.16 Qué debes recordar de este tema
- El lenguaje ubicuo es un vocabulario compartido por negocio y equipo técnico.
- Debe aparecer en conversaciones, requerimientos, casos de uso, modelos, pruebas, documentación y código.
- Ayuda a reducir ambigüedad y a mejorar la comunicación.
- Los expertos del negocio son esenciales para definir términos correctos.
- Un glosario vivo ayuda a mantener definiciones, ejemplos y reglas asociadas.
- Las palabras ambiguas y los sinónimos innecesarios deben analizarse con cuidado.
- Un buen lenguaje ubicuo mejora el modelo de dominio y facilita el mantenimiento del sistema.
4.17 Conclusión
El lenguaje ubicuo permite que el equipo construya software hablando el mismo idioma que el negocio. No se trata solo de elegir nombres bonitos, sino de capturar significados precisos y mantenerlos consistentes durante todo el proyecto. Cuando el vocabulario es claro, los requerimientos se entienden mejor, los modelos son más útiles, las pruebas son más expresivas y el código conserva mejor el conocimiento del dominio.
En el próximo tema veremos cómo descubrir conceptos del dominio a partir de entrevistas, documentos y otras fuentes de información.