La ubicuidad del lenguaje

Aunque no lo parezca, estoy hablando de un patrón de modelado, más cercano a las buenas prácticas pero patrón al fin. El lenguaje ubicuo es uno de los patrones más interesantes en el arte del modelado de dominio. Como muchos patrones, su idea es simple: Usar el mismo lenguaje en el nivel de los expertos de dominio (usuarios, clientes, operadores del sistema) que en el de los modeladores (usualmente desarrolladores de software o analistas de procesos).

La idea de usar el mismo lenguaje en todos los niveles involucrados en el sistema y en su observación puede parecer un poco ingenua, pero en realidad es una tarea difícil con interesantes resultados.

Supongamos que estamos realizando un software para el control de expedientes de un hospital, si yo hablara de registros de datos asociados mediante un identificador a un único paciente y el personal del hospital se refiriese a esto mismo con el nombre de expediente clínico, sin duda podríamos llegar a entendernos eventualmente. Que sucede cuando tenemos que hablar de los registros por visita, que sin duda, forman parte del expediente. Yo puedo nuevamente considerar registros de datos asociados ahora a un identificador único de “expediente” (que es mi registro asociado a un único paciente) y seguir adelante.

 El problema de esta manera de trabajar es que tarde o temprano, la comunicación se hará muy complicada, mientras ellos hablan de pacientes, médicos, expedientes, visitas, etc., yo hablo de registros en tablas de una base de datos, no importa que en la tabla de pacientes tenga nombre, apellido y fecha de nacimiento, reflejando de manera natural las propiedades de un paciente, el problema es que lo que ellos llaman paciente yo lo llamo registro (o entrada) de la tabla pacientes.

El patrón del lenguaje ubicuo pide que el lenguaje sea el mismo, y en este caso, no son los expertos del hospital los que deben hablar de bases de datos, sino los desarrolladores los que debemos hablar de pacientes, médicos, expedientes y todo lo demás, pero no sólo debemos hablar en el mismo idioma que los expertos del hospital, sino que debemos llevar este mismo lenguaje a todo nuestro proceso, en particular, a nuestro código.

Este es un enfoque que muchos desarrolladores orientados a objetos manejan de manera intuitiva, pero a veces incompleta. La gracia está en que nuestros objetos en el código hagan lo mismo que los objetos del sistema y del proceso real que representan, pero más aún, que se relacionen entre sí de la misma manera que en el sistema real.

Aquí debo hacer una aclaración para quienes no estén familiarizados con la teoría general de sistemas: un sistema es una abstracción arbitraria por parte del observador, dónde acaba y dónde termina un sistema, cuáles son subsistemas, etc. son decisiones de la persona que describe el sistema, no características inherentes al sistema mismo.

Regresando a nuestros objetos en el software que mapean a los objetos del sistema, decía que lo más importante es su relación entre sí, lo que llamamos comportamiento en un elemento de un sistema sólo se puede entender en términos de otros elementos. Nuestros objetos deben emular las relaciones que tienen los elementos del sistema, o dicho de otra manera, debemos poder hablar de nuestros objetos de la misma manera en la que se habla en el nivel del dominio, regresando al ejemplo: en el nivel de los expertos del hospital. Se trata de poder usar el mismo lenguaje.