Hey devs, en esta ocasión tengo un artículo que he visto que no se profundiza mucho ni se habla lo que se debería del tema, pero que es importantísimo si quieres dar ese paso a convertirte en un desarrollador excelente, comencemos!
Introducción
En el desarrollo de software, uno de los mayores retos es modelar sistemas complejos de manera que sean mantenibles, escalables y alineados con el negocio. Dos enfoques arquitectónicos ampliamente adoptados para lograr esto son Domain-Driven Design (DDD) y Clean Architecture. Aunque son conceptos distintos, Clean Architecture toma muchos principios de DDD, especialmente en la separación de responsabilidades y en la forma de estructurar el dominio del sistema.
Este artículo explorará los conceptos fundamentales de DDD, sus enfoques estratégicos y tácticos, y cómo estos se relacionan con Clean Architecture.
¿Qué es Domain-Driven-Design (DDD)?
Domain-Driven Design es un enfoque de diseño de software introducido por Eric Evans en su libro Domain-Driven Design: Tackling Complexity in the Heart of Software (2003). Su propósito es modelar software basado en las reglas y procesos del negocio, asegurando que el código refleje fielmente el dominio de la aplicación.
DDD enfatiza la colaboración entre expertos del dominio y desarrolladores, fomentando el uso de un Lenguaje Ubicuo que asegure una comprensión compartida de los conceptos del negocio.
DDD no es una metodología, sino más bien una especie de filosofía y por eso no tiene un número definido de principios.
Enfoques de DDD: Strategic y Tactical
Aunque los términos Strategic design y Tatical design no aparecen explícitamente en el libro original "Domain Driven Design" de Eric Evans, el autor sí describe los conceptos que hoy conocemos como diseño estratégico y táctico y la comunidad de DDD los formalizó con el tiempo.
DDD se divide en dos enfoques complementarios:
1. Strategic DDD (Diseño Estratégico)
Se enfoca en la estructura global del dominio y en cómo dividirlo en módulos independientes mediante los siguientes conceptos:
- Bounded Context (Contexto Delimitado): Define los límites de un modelo de dominio, evitando la contaminación entre diferentes áreas del negocio. Por ejemplo: Un sistema de e-commerce puede tener contextos como Catálogo, Pedidos, Facturación y Logística, cada uno con su propio modelo de "Producto" o "Cliente".
- Ubiquitous Language (Lenguaje Ubicuo): Un lenguaje común entre desarrolladores y expertos del dominio para mejorar la comunicación y reflejarse en el código.
- Context Mapping (Mapeo de Contextos): Muestra la relación entre distintos Bounded Contexts, definiendo cómo interactúan.
2. Tactical DDD (Diseño Táctico)
Se enfoca en cómo implementar el modelo de dominio dentro de un Bounded Context. Aquí el foco está en el "cómo" técnico, usando patrones concretos. El objetivo es crear un modelo de dominio rico, mantenible y alineado con el lenguaje ubicuo.
- Entidades: Objetos con identidad única y ciclo de vida definido, por ejemplo Usuario, Producto, Orden.
- Objetos de Valor (Value objects): Objetos sin identidad, definidos solo por sus atributos. Por ejemplo: dirección, dinero, fecha.
- Agregados: Conjunto de entidades que se tratan como una unidad coherente, por ejemplo Orden con su DetalleOrden.
- Repositorios: Proveen acceso a la persistencia de agregados.
- Servicios de Dominio: Contienen lógica que no pertenece a una sola entidad.
- Eventos de Dominio: Representan cambios o sucesos importantes en el dominio, por ejemplo OrdenCreada, PagoRealizado, ProductoReservado.
Principios de DDD
Aunque en el libro de Evans no hace categorías de los principios de DDD, generalmente la comunidad y los que aplican DDD las agrupan en 2:
Principios Fundamentales de DDD
| Principios | Descripción |
|---|---|
| 1. Modelado basado en el dominio | El código debe reflejar con precisión el negocio. |
| 2. Lenguaje Ubicuo (Ubiquitous Language) | Un lenguaje común entre desarrolladores y expertos del dominio. |
| 3. Bounded Contexts (Contextos Delimitados) | Separar el dominio en áreas bien definidas para evitar ambigüedades. |
| 4. Énfasis en el Core Domain | Priorizar el desarrollo en la parte más valiosa del negocio. |
| 5. Diseño evolutivo del modelo | El modelo debe cambiar conforme evoluciona el negocio. |
| 6. Diseño explorado en colaboración | Los expertos del dominio deben participar activamente en la definición del modelo. |
Principios Técnicos y de Diseño Aplicados en DDD
| Principios | Descripción |
|---|---|
| 7. Persistence Ignorance (Ignorancia de la Persistencia) | El dominio no debe depender de bases de datos ni de infraestructura. |
| 8. Rich Domain Model (Modelo de Dominio Rico) | Los objetos encapsulan tanto datos como comportamiento. |
| 9. Independencia del Dominio (Domain Independence) | La lógica del dominio debe estar desacoplada de la infraestructura. |
| 10. Separación de Intereses (Separation of Concerns, SoC) | Diferenciar responsabilidades entre capas (Dominio, Aplicación, Infraestructura, Presentación). |
| 11. Encapsulación de la lógica de negocio | La lógica del dominio debe estar dentro de las entidades y agregados, no en servicios externos innecesarios. |
| 12. Diseño basado en eventos (Event-Driven Design) | Modelar el dominio mediante eventos de negocio relevantes. |
| 13. Uso de Agregados | Garantizar la consistencia y coherencia de los datos agrupando entidades relacionadas. |
| 14. CQRS (Command Query Responsibility Segregation) | Separar operaciones de lectura y escritura para mejorar la escalabilidad y el modelado del dominio. |
Métodos y técnicas de DDD
Entre las técnicas y métodos que ayudan a aplicar DDD, tenemos:
- Event Storming – Técnica colaborativa para descubrir eventos y modelar procesos de negocio.
- Event Modeling – Técnica visual para diseñar sistemas basados en eventos.
Relación entre Clean Architecture y DDD
De los 14 principios que te listé, Clean Architecture toma la mayoría, como siempre digo, Clean Architecture se sirve de lo que necesita de DDD, entonces te puedo decir que toma todos menos el número 2, 3 y el 12 los cuales son Lenguaje ubícuo, Bounded contexts y Event-driven design.
No es que estén prohibidos de ser utilizados en Clean Architecture, sino que su adopción es opcional ya que Clean Architecture por ejemplo no fuerza el uso ni de Bounded Contexts ni del lenguaje ubicuo, ni de event-driven design.
Conclusiones
Pues bien estimado dev como habrás notado Domain-Driven Design y Clean Architecture no son enfoques excluyentes, sino complementarios. DDD proporciona principios estratégicos y tácticos para modelar un dominio de negocio complejo, mientras que Clean Architecture estructura el software en capas independientes, asegurando mantenibilidad y escalabilidad.
Al combinar ambos enfoques, podemos construir sistemas robustos donde la lógica del negocio sea clara, desacoplada y sostenible en el tiempo. Si quieres saber más de esta genial arquitectura como Clean, en este artículo te cuento el porqué debes aprenderla.
Y por si te interese, dicto cursos sobre Clean Architecture con proyectos reales, también abordo otras arquitecturas, así que no dudes en contactarme si necesitas una mano en esto! 🐿️🔥
Si esta entrada te ha gustado, compártela crack!
Créditos de imagen de portada: Foto de Alex Brisbey en Unsplash
Un comentario en «Domain-Driven-Design y su relación con Clean Architecture»