Aprende DDD Domain-Driven Design parte 1

Probablemente, hayas escuchado hablar de DDD (Domain-Driven Design) en varias ocasiones e incluso leído algún artículo o realizado algún curso, pero aún no lo entiendes del todo y no te atreves a aplicarlo en un proyecto.

No te preocupes, a mí me pasó lo mismo. La mayoría de los recursos disponibles están llenos de teoría y términos que, en lugar de aclarar, generan más confusión. 

Además, muchos carecen de ejemplos prácticos o presentan estructuras tan diferentes entre sí que terminan desorientándonos. También existen cursos con un nivel de complejidad innecesario, donde se añaden detalles que poco tienen que ver con DDD, haciéndonos perder de vista lo realmente importante: aprender a usarla.

En cuanto a las estructuras, no te preocupes. Mientras sigamos las capas fundamentales, podemos permitirnos cierta flexibilidad dentro de ellas. Una vez comprendas bien estas capas, serás capaz de interpretar y trabajar en cualquier proyecto basado en DDD.

¿Qué es DDD? 🤔

Significa (Domain-Driven Design, o Diseño Guiado por el Dominio). Y como su nombre indica, es el desarrollo de nuestra aplicación guiado por el dominio.

Pero, ¿Qué quiere decir realmente esto?

Imagina que quieres construir una web para una tienda en línea. Hay muchas partes en el sistema: los productos, los clientes, los pedidos, los pagos, etc. DDD es una forma de organizar y estructurar tu código para que se enfoque en cómo funciona el negocio en la vida real.

En lugar de empezar pensando en la base de datos o en las pantallas de usuario, como hacemos normalmente, DDD primero se centra en entender el negocio y reflejarlo en el código de manera clara y organizada.

🔑 Conceptos básicos de DDD

📌 1. El Dominio (Domain)

El "Dominio" es simplemente el problema o área de conocimiento que estás resolviendo con tu aplicación.

Ejemplo: Imagínate que eres freelance y uno de tus clientes quiere que le crees una web para una tienda online, el dominio es la "venta de productos en línea".

📌 2. Modelo del Dominio (Domain Model)

El modelo del negocio es el conjunto de reglas y lógica que describen cómo funciona el negocio. En nuestro ejemplo de tienda online, el código trata de representar cómo nuestro cliente, describe su trabajo.

Ejemplo:

• Un cliente puede hacer un pedido.
• Un pedido tiene una lista de productos y un precio total.
• Un producto tiene un stock, y si se agota, no se puede comprar.

En Domain-Driven Design (DDD), el modelo de dominio representa la lógica central de negocio con clases puras, sin depender de infraestructura (como bases de datos o frameworks).

Las clases del modelo de dominio deben:
✔ Representar conceptos del negocio.

✔ No depender de un Framework, bases de datos, ni controladores.

✔ Encapsular la lógica y reglas de negocio. 

📌 ¿Por qué separar el dominio?

✅ Facilita cambios sin romper toda la aplicación.
✅ Puedes probar la lógica del negocio sin depender de la base de datos. Como veremos más adelante, esto nos va a ayudar enormemente a la hora de hacer tests.
✅ Evita que un framework u ORM controlen tu modelo de negocio.

📌 3. Lenguaje Ubicuo (Ubiquitous Language)

Es un lenguaje común entre los desarrolladores y expertos del negocio (en este caso, nosotros y nuestro cliente) para que todos hablen el mismo idioma.

Ejemplo:
En vez de usar nombres técnicos como Tbl_Orders, en DDD, diríamos Pedido, porque así lo llaman los dueños del negocio.

Esto hace que el código sea fácil de entender tanto para programadores como para personas no técnicas.

Si quieres mantener un estilo en inglés en todo el código, que es lo que yo te recomiendo, pero tu cliente usa términos en español, lo ideal es definir un Glosario del Lenguaje Ubicuo donde:

✅ Se documenten los términos clave en español e inglés.
✅ Se acuerde un conjunto de términos en inglés que todos (tú y el cliente) usarán.
✅ Se mantenga la coherencia en nombres de clases, métodos, variables y tablas.

📌 Ejemplo: Tienda Online (Español → Inglés)

Supongamos que tu cliente usa términos en español:

• Pedido → Order
• Cliente → Customer
• Producto → Product
• Carrito de compras → ShoppingCart

📌 Glosario documentado para el equipo

🎯 ¿Cómo asegurarnos de mantener el lenguaje consistente?

✅ Documentar el glosario y compartirlo con el equipo.
✅ Usar siempre inglés en el código (clases, métodos, variables, base de datos).
✅ Comunicar el mapeo al cliente, explicando que en código usamos inglés, pero sigue representando su negocio.
✅ Evitar mezclar idiomas (ejemplo incorrecto: PedidoService en vez de OrderService).

📌 4. Entidades y Objetos de Valor

DDD divide los datos en dos tipos principales:

• Entidades: Tienen un identificador único y pueden cambiar con el tiempo.
   Ejemplo: Un Producto con un ID y un stock que va a cambiar.
• Objetos de Valor (Value Objects): No tienen identidad propia y son inmutables.
   Ejemplo: Stock de un producto, podemos crear un value object para el stock en que podremos añadir las validaciones necesarias como que no acepte un número negativo. No te preocupes si no lo entiendes porque lo vamos a ver a fondo cuando nos metamos con el código.

📌 5. Agregados (Aggregates)

Son grupos de objetos que deben mantenerse juntos como una unidad.

Ejemplo:
Un Pedido tiene que tener siempre Productos y un pedido sin ningún producto no tiene sentido de existencia. No podemos modificar un Producto dentro de un Pedido sin afectar al Pedido completo.

El Pedido sería el Agregado, y los Productos serían parte de él.

📌 6. Repositorios (Repositories)

Son las "puertas de entrada" para acceder y almacenar información en la base de datos sin que los objetos del dominio se preocupen por los detalles técnicos, siguiendo el principio de responsabilidad única de SOLID.

Por ejemplo, en lugar de que un Pedido acceda directamente a una base de datos, usamos una clase PedidoRepositorio que maneja la lógica de guardar pedidos, actualizarlos, borrarlos, listarlos o recuperar uno por su identificador.

Entonces solo necesitamos poder convertir los valores de nuestro dominio a una entidad como puede ser de Doctrine y desde PedidoRepositorio manejaremos el tratamiento de los datos como una inserción, actualización, listado de datos, etc.

En el dominio, crearemos una interfaz PedidoRepositorioInterface para definir que acciones podrá realizar PedidoRepositorio.

📌 7. Servicios de Dominio (Domain Services)

A veces, una operación no pertenece a una sola entidad, sino que afecta a varias. Para esos casos usamos Servicios de Dominio.

Un ejemplo de regla de negocio sería que un Cliente no pudiera realizar un pedido de un producto sobre más stock del que tenemos de un producto. En este caso no pertenece solo al Pedido y al Producto, sino a los dos.

Fin de la primera parte

Como se está haciendo muy larga esta parte teórica, lo he dividido en dos partes. Puedes continuar la siguiente parte de este tutorial desde el siguiente enlace:

https://cosasdedevs.com/posts/aprende-ddd-domain-driven-design-parte-2

Espero que este post te ayude y como siempre, te recomiendo seguirme en Twitter para estar al tanto de los nuevo contenido. Ahora también puedes seguirme en Instagram donde estoy subiendo tips, tutoriales en vídeo e información sobre herramientas para developers.

Por último os dejo mi guía para aprender a trabajar con APIs donde explico todo el funcionamiento de una API, el protocolo HTTP y veremos como construir una API con arquitectura REST.

Nos leemos 👋.