Una de las primeras cosas que se oye cuando se habla de DDD es el termino "*Lenguaje Ubicuo*". Es la base de todo en DDD, usando este lenguaje podremos definir todos los conceptos de nuestro negocio, nos ayudará a comunicarnos correctamente y ante todo, nos facilitará la tarea de modelar correctamente el dominio de nuestra solución. Empecemos por definir "Lenguaje": > Facultad del ser humano de expresarse y comunicarse con los demás a través del sonido articulado o de otros sistemas de signos. Bien, ahora definamos "Ubicuo": > Que está presente a un mismo tiempo en todas partes. Dadas estas dos definiciones podemos asumir que un **Lenguaje Ubicuo es una forma de comunicación que se usa en todas partes**.

Quieto todo el mundo, que no panda el cúnico. ¿Partes? ¿Qué partes? Pues partes de nuestro **proyecto**, que bien podrían ser, **negocio** y **desarrollo** entre otras. Como ya sabemos, todo negocio tiene su jerga, su manera de definir y nombrar las cosas. El Lenguaje Ubicuo busca integrar esta jerga de manera eficiente y fácil en todos los ambitos del proyecto. De manera que todos los integrantes de las partes interesadas que desarrollan el proyecto, llamen a las cosas por los mismos términos. ### Definiendo el Lenguaje Ubicuo Supongamos que somos un estudio de software que va a desarrollar una aplicación para un cliente. Este, empieza a describir su negocio: "_Somos una empresa de logística de transportes, disponemos de varias flotas de vehículos de distintos modelos y características. Uno o varios vehículos o incluso la flota entera puede salir en misión, es decir, ser alquilada por nuestros clientes..._". Como vemos, el cliente ha usado ciertos términos propios de su negocio, como por ejemplo, _vehículo_, _flota_, _modelo de vehículo_, _característica de vehículo_, _misión_.Todos estos términos **deben** formar parte de nuestro _lenguaje ubicuo_. Además de todos estos sustantivos, el cliente puede utilizar verbos que definan acciones u operaciones específicas de su negocio. Lo mas seguro es que los sustantivos acaben siendo _Entidades_ o _Value Objects_ y los verbos acaben siendo _servicios de aplicación_ o _servicios de dominio_. Veamos un ejemplo de como definir estas entidades usando UML:

Continuamos con la conversación, "_¿Cuáles son las características de una flota?_" le preguntamos, a lo que el cliente responde, "_Cada flota está identificada por una referencia única, además tiene un nombre y una base asociada._". Seguimos preguntando, "_¿Qué formato debería tener el identificador? y ¿qué es una 'base'?_". El cliente nos comenta "_El identificador de las flotas y de los vehículos es un identificador único universal. La base es la referencia del emplazamiento físico donde la flota está estacionada, también es un uuid._". Actualicemos el esquema anterior:

Continuaremos con la conversación hasta que, tanto el cliente como nosotros, estemos satisfechos con el modelo inicial de la solución. ### Implementando el Lenguaje Ubicuo El lenguaje ubicuo no solo se limita a la comunicación con nuestro cliente, tiene que formar parte intrínseca de la solución que estamos construyendo, por ejemplo:

final class Fleet
{
	private $id;
	
	private $name;
	
	private $baseId;
	
	public function __construct(FleetId $id, FleetName $name, BaseId $baseId)
	{
		$this->id = $id;
		$this->name = $name;
		$this->baseId = $baseId;
	}
}

final class Vehicle
{
	private $id;
	
	private $fleetId;
	
	private $status;
	
	public function __construct(VehicleId $id, FleetId $fleetId, VehicleStatus $status)
	{
		$this->id = $id;
		$this->fleetId = $fleetId;
		$this->status = $status;
	}
	
	public function isInMission(): bool
	{
		return ($this->status === VehicleStatus::IN_MISSION);
	}
}

En este ejemplo vemos como el código de nuestra solución está llena de términos de nuestro lenguaje ubicuo. Hemos creado un metodo `isInMission` en la clase `Vehicle` que refleja directamente un concepto del modelo de negocio de nuestro cliente. Es recomendable tener nuestro lenguaje ubicuo escrito y totalmente documentado, para que, en caso de duda podamos consultar cualquier término. Además, esto ayudará a los nuevos miembros del equipo a familiarizarse con el lenguaje ubicuo. Como podemos ver, la manera de crear un lenguaje ubicuo es sencilla, solo debemos de conversar con nuestro cliente, asimilar la terminología de su negocio y aplicarla para modelar el dominio. Es muy importante definir correctamente un lenguaje ubicuo adecuado, ya que esto favorecerá una correcta comunicación entre nuestro cliente y nuestro equipo de desarrollo. Si nuestro cliente nos comenta que necesita cambios en la administración de las flotas, nosotros tenemos que saber al 100% a que se está refiriendo. ### Conclusión En resumen podemos decir que: - El lenguaje ubicuo busca unificar la comunicación entre todas las partes interesadas del proyecto. - Todos los integrantes de las partes interesadas en el proyecto deben usarlo con fluidez. - Contiene términos propios del negocio para el cual se esta definiendo el lenguaje. - Nos ayuda a modelar el dominio de nuestro negocio y trasladarlo facilmente a nuestra solución.