En todas las empresas en las que he trabajado, siempre surge un problema, cuando algo nuevo aparece si la persona que ha motivado su introducción no sabe su nombre: se la inventa. No suele ser un problema porque toda la empresa conoce el término, la tecnología o el elemento dentro de sus sistema por ese nombre, pero para nuevas personas en el proyecto, puede resultar frustrante, ¿qué nombre elegir mejor?
Actualizado (19/07/2022): después de leer información sobre lenguaje ubicuo de Domain-Driven Design (DDD), creo que es una definición y un concepto mucho más claro así que he rectificado el artículo para recoger un Modelo de Dominio más próximo al lenguaje ubicuo.
Esto pasa con mucha frecuencia, y no es malo, pero es común que toda la empresa termine usando el vocablo en muy poco tiempo y, toda persona que entre nueva, si ese vocablo le parece desconocido o le sugiere otra cosa distinta, le lleve a confusión hasta que se lo expliquen.
Para esto se suelen hacer glosarios o un modelado completo con definiciones y diagramas. En ingeniería del software se conoce como: Modelo de Dominio; y en Diseño Guiado por Dominio (o en inglés Domain-Driven Design, DDD) como Lenguaje Ubicuo.
Modelo de Dominio y Lenguaje Ubicuo
Aunque a mi me gusta ver ambos como un glosario de términos al que recurrir cuando se tienen dudas sobre la jerga empleada dentro de una empresa, es cierto que el Modelo de Dominio puede ser más completo. Sería como una enciclopedia donde se especifica no solo la definición sino también se aportan relaciones con otros términos, un poco de historia, evolución, composición y diagramas para completar y entender mejor el dominio donde la empresa trabaja.
El lenguaje ubicuo en este aspecto queda más superficial. La definición suele ser suficiente y no es necesario aportar mucho más. En DDD disponemos de más artefactos para obtener información del dominio que quedan fuera del alcance del documento donde recogemos el lenguaje ubicuo.
¿Qué debemos recoger o qué podemos indicar dentro de un documento así?
Contenido y organización de un glosario
El modelado del dominio es en ocasiones complejo. Lo ideal para cumplir con las especificaciones de un bueno modelo e incluso un documento de lenguaje ubicuo es definir todas las palabras que normalmente se emplean en la empresa, en el vertical en el que trabajamos y que normalmente debemos explicar siempre a las personas que entran nuevas a trabajar en la empresa.
Si alguien pregunta por el significado de una palabra, esa palabra debe ir ineludiblemente al documento. Si esa palabra no ofrece una explicación clara, debe reformularse y si la definición requiere de agregar un poco más de contexto, es buena idea agregar ejemplos de su uso e incluso relación con otras palabras o diagramas que permitan un mejor entendimiento.
Por ejemplo, trabajando en un vertical como el trading donde se manejan muchos términos desconocidos para personas que no han trabajado en este sector y que debemos contratar por no hallar suficientes profesionales que conozcan la tecnología en la que deben trabajar y al mismo tiempo la jerga propia del vertical, nos obliga a agregar palabras en el glosario como: activos, amortización, apalancamiento, ask, bid, call cubierta, etc.
Cuantos más términos empleemos tal y como se emplean en el sector más podremos beneficiarnos de glosarios ya desarrollados para nuestro propio sector necesitando agregar únicamente aquellos cuyo significado empleemos de forma diferente o con un sentido más específico o directamente nos hayamos inventado.
Nombres de las cosas
Además de los nombres propios de los verticales donde trabajamos, nuestra empresa puede ser muy prolífica a la hora de agregar nombres a elementos creados dentro de la empresa. Aún teniendo un nombre específico fuera de la empresa, si dentro se conoce con otro nombre y hay consenso en utilizar ese nombre, está bien. Siempre y cuando se pueda transmitir el significado de ese nombre y no lleve a equívocos.
Como decía Phil Karlton: "Hay solo dos cosas difíciles en Ciencias de la Computación: invalidación de caché y nombrar cosas". Los nombres de los elementos dentro del código, comentarios y documentos debe ser por tanto unívoco. Si cuesta nombrar bien algo imagínate intentar nombrarlo dos veces. Al final, si no tenemos en cuenta los nombres que le damos a cada elemento terminamos con un sistema difícil de entender.
Conclusiones
Mantener un glosario de términos accesible para toda la empresa y que permita agregar sugerencias de todos y cada uno de los empleados nos puede ayudar a mantener un entendimiento unificado y claro no solo para los empleados que trabajan a día de hoy en la empresa sino también para nuevas incorporaciones.
¿En tu empresa hay un glosario, documento de lenguaje ubicuo o modelo de dominio accesible para todos? ¿Sabías que existía pero no consideras que sea muy importante? ¿Has sugerido crearlo pero no sabías como defenderlo? ¡Déjanos tu comentario!
