Hoy hablamos de un tema muy popular en los entornos empresariales: DDD o Domain Driven Design. A menudo se presenta como algo super complejo porque se suele explicar entrelazado con patrones como Event Sourcing, CQRS o procesos como Event Storming. Si bien pueden ir juntos, son prácticas diferentes que se pueden, y deberían (si quien lo explica sabe de lo que habla) hacerlo de una forma independiente si realmente se busca entender la base del diseño dirigido por el dominio.
Tabla de contenidos
1 - Qué es Domain Driven Design?
Domain Driven Design (DDD) no es más que la creación de un modelo de dominio para entender cómo el dominio del negocio funciona.
Y cuando decimos dominio del negocio nos referimos a las reglas de negocio y el contexto sobre esas reglas.
Imagina que estamos construyendo un software para una empresa logística. El "Dominio" no es el código, sino el acto físico de mover paquetes de un punto A a un punto B.
Utilizar Domain Driven Design no afecta únicamente al código como podría parecer, sino que busca que el software sea un reflejo exacto de estas realidades físicas y legales, no una simple base de datos con una interfaz encima. Para ello hay varias partes que son clave y que debemos aplicar correctamente.
1.1 - Un vocabulario común en Domain Driven Design
Es crucial que todas las personas implicadas en el proyecto utilicen el mismo vocabulario.
Todo el equipo se tiene que poner de acuerdo, normalmente guiados por expertos en el dominio para definir dicho vocabulario
Esto puede parecer muy sencillo a primera vista, pero no lo es ya que tanto ingenieros, gente de negocio o rangos intermedios pueden llamar de distinta forma a la misma acción.
Por ejemplo, en nuestra empresa de envíos, queremos poner un dispositivo para trackear la localización de los vehículos, a este dispositivo como lo llamamos? Tag (como un AirTag), Beacon (porque emite señales), tracker (porque rastrea la localización), locator, o incluso telemetry unit si lo que hace es enviar algo más de información además de simplemente las coordenadas GPS.
Definir este vocabulario es CLAVE para no perder tiempo a mitad del proyecto y evitar confusiones, lo que viene siendo el Ubiquitous Language.
1.2 - Las entidades en Domain Driven Design
Por relacionarlo con el ejemplo anterior, una entidad es un objeto que tiene una identidad única que persiste en el tiempo, independientemente de si sus atributos cambian.
En nuestro sistema de envíos, un camión es una entidad. Aunque lo pintemos de otro color, le cambiamos las ruedas o se le asigne un conductor nuevo, sigue siendo el mismo camión (identificado por la matrícula). Lo que nos importa no es solo su estado actual, sino quién es a lo largo de su vida en el sistema.
1.3 - El contexto en Domain Driven Design
El contexto es otra parte crucial dentro de DDD ya que lo que haremos es dividir áreas complejas del dominio en partes más pequeñas, denominadas bounded context, donde cada una tendrá su propio vocabulario, implementaciones, definiciones, etc.
Esto quiere decir que la misma palabra, puede significar dos cosas diferentes en diferentes contextos.
Un pedido para el departamento de ventas no tiene que significar lo mismo que para el departamento de logística o para el departamento contable.
1.4 - Value objects en Domain Driven Design
Un Value Object (Objeto de Valor) define aspectos del dominio que no tienen identidad propia; lo que importa son sus atributos. Si cambias un atributo, tienes un objeto nuevo.
En nuestro ejemplo la dirección de entrega (Calle, Código Postal, Ciudad) es un Value Object. Si cambias el código postal, ya no es la misma dirección sino que es una dirección distinta.
1.5 - Aggregates en Domain Driven design
Un Aggregate es tan sencillo como tener un grupo de entidades y value objects que se tratan como una única unidad de cara a la consistencia de datos. Cada agregado tiene una "Raíz" al que técnicamente llamamos Aggregate Root.
En la empresa de transportes tenemos los envíos que contienen la entidad Envio, una lista de paquetes y una Ruta.
Cuando cambiamos el estado del envío a entregado no lo hacemos paquete por paquete sino que lo hacemos a través del envío, asegurándonos que todos los paquetes cumplan con las reglas antes de marcarlo como completado. El agregate garantiza que nada dentro del mismo tiene un estado inválido.
1.6 - Los eventos de dominio en Domain driven design
Finalmente tenemos los eventos de dominio (o domain events) estos eventos son situaciones o acciones que suceden en otras partes del dominio a los que debemos reaccionar.
Ojo, es importante saber distinguir que esto son eventos dentro de nuestro dominio, si suceden en un dominio diferente, para nosotros son simplemente eventos externos o integraciones.
Su mayor uso es para desacoplar partes del sistema y para reaccionar a las acciones o eventos que suceden.
2 - Ventajas de usar Domain Driven Design
La ventaja más clara y evidente para quien haya trabajado con DDD desde la parte técnica es que los desarrolladores pasan a conocer el dominio en el que trabajan.
Puedes pensar que esto es lo normal, pero en mi carrera profesional la mitad de la gente con la que he trabajado les va justo para saber qué es lo que la empresa hace. Así que el cómo lo hace, les da exactamente igual y eso se nota al hacer software ya que con DDD tienen el mundo real más en la mente.
Que los ingenieros se preocupen por las reglas y cómo funciona el dominio hace que todo sea más fluido a largo plazo, ya no solo la relación entre desarrolladores y el resto de partes de la empresa, sino a la hora de comprender la complejidad de lo que hace la empresa.
Muchos desarrolladores están en una cueva donde solo les importa su código y ya, lo que mirado desde el punto de vista de la empresa, no es bueno.
Respecto a DDD y la parte técnica por norma general el código es más legible, porque se utiliza el mismo vocabulario que en la parte de dominio por lo que es fácil de mantener entender y comúnmente extender si el dominio crece.
3 - Donde no utilizar Domain Driven Design
Por norma general DDD brilla en dominios complejos. Si estás haciendo un CRUD sencillo o un microservicio que simplemente transforma datos, aplicar DDD completo es sobreingeniería. El coste de alinear vocabulario, definir bounded contexts y modelar agregados sólo se justifica cuando la complejidad del negocio lo requiere.
Por norma general si el problema se entiende leyendo el esquema de la base de datos lo más probable es que no necesitas DDD.
4 - Conclusión
Domain Driven Design, aunque en mi blog lo he metido en la parte de arquitectura, no es una arquitectura técnica, sino una filosofía de diseño. El objetivo es que tu software entienda el negocio de verdad teniendo las mismas consistencias que en el mundo real, dejando a un lado las librerías de moda.
