Domain-Driven Design, ¿Qué es y cómo aplicarlo en mi organización?
¿Qué es el Domain-Driven Design (DDD)?
En 2003, Eric Evan publicó su libro titulado “Tackling Complexity in the Heart of Software”, en el cual laza los primeros conceptos de DDD (Domain-Driven Design), aumentando su popularidad de manera exponencial desde entonces.
Muchos equipos, empresas y organizaciones han aplicado este modelo y adquirido grandes éxitos en el desarrollo de software.
El Domain-Driven Design (DDD) no es una tecnología ni una metodología, sino una práctica de desarrollo de software con necesidades complejas, que sitúa el Dominio del Negocio como faro del proyecto y en su Modelo, como herramienta de comunicación entre negocio y tecnología.
¿Cómo se aplica el Domain-Driven Design (DDD)?
Como sabemos, la mayoría de las aplicaciones de empresa con una significativa complejidad empresarial y técnica se definen a partir de múltiples niveles. Estos niveles son un elemento lógico y no están relacionados con la implementación del servicio, sino que sirven para ayudar a los desarrolladores a administrar la complejidad del código.
Pongamos un ejemplo:
Tomemos de ejemplo una entidad se puede cargar desde la base de datos.
Puede ser que se envíe parte de esa información de la base de datos a la interfaz de usuario del cliente a través de una API web REST.
La cuestión aquí es, que la entidad de dominio se debe situar dentro del nivel de modelo de dominio y no puede propagarse a otras áreas a las que no pertenece, como al nivel de presentación.
Además, las entidades no pueden estar enlazadas a vistas de cliente, porque puede ser que algunos datos no estén validados en el nivel de la interfaz de usuario.
ViewModel
Pero ese es el propósito de ViewModel, un modelo de datos exclusivo para las necesidades del nivel de presentación. Pero las entidades de dominio, no pertenecen directamente al modelo ViewModel. Por lo que debemos traducir entre ViewModels y entidades de dominio, y viceversa.
¿Qué niveles tiene Domain-Driven Design?
Veamos a continuación un diseño de capas del microservicio DDD:
En la imagen de anterior, podemos ver un diseño a tres capas del microservicio DDD Ordering.
Cada capa es un proyecto de VS:
- La capa de aplicación es Ordering.API
- El nivel de dominio es Ordering.Domain
- El nivel de infraestructura es Ordering.Infrastructure
Es muy importante para su correcto funcionamiento que cada nivel se comunique solamente con otros niveles determinados. Además, este enfoque de desarrollo puede ser más fácil de aplicar si los niveles se implementan como bibliotecas de clase distintas, ya que nos permite identificar claramente qué dependencias se establecen entre las distintas bibliotecas.
Los 3 niveles de Domain-Driven Design (DDD)
Modelo de dominio
El nivel de modelo de dominio es el nivel responsable de representar conceptos del negocio, información sobre la situación del negocio y reglas de negocios.
El estado que refleja la situación empresarial está controlado y se usa aquí, pero los detalles técnicos de su almacenaje se delegan a la infraestructura.
Podemos decir que este nivel es el núcleo del software empresarial.
Aplicación
El nivel de aplicación define los trabajos y tareas que se supone que debe hacer el software y dirige los objetos de dominio expresivo para que resuelvan problemas.
Las tareas que son responsabilidad de este nivel son significativas para la empresa o necesarias para la interacción con los niveles de aplicación de otros sistemas, por lo que este nivel debe mantenerse estrecho.
Este nivel no contiene reglas de negocios ni conocimientos, sino que solo coordina tareas y delega trabajo a colaboraciones de objetos de dominio en el siguiente nivel.
Además, no cuenta con ningún estado que refleje la situación empresarial, pero puede tener un estado que refleje el progreso de una tarea para el usuario o el programa.
Infraestructura
El nivel de infraestructura es la forma en que los datos que inicialmente se conservan en las entidades de dominio, en la memoria, se guardan en bases de datos o en otro almacén permanente.
Un ejemplo sería usar código de Entity Framework Core para implementar las clases del patrón de repositorio que usan DBContext para conservar los datos en una base de datos relacional.
A continuación, podéis observar las dependencias, idóneas, que debería tener cada capa en un servicio de Domain-Driven Design:
Como podemos ver en el esquema anterior, la capa de aplicación depende del dominio y la infraestructura, y la infraestructura depende del dominio, pero el dominio no depende de ninguna capa.
¿Ventajas y desventajas del modelo?
Como todos los modelos, el Domain-Driven Design cuenta con beneficios a su favor y algunas desventajas en su contra, pero como siempre os decimos, dependiendo de vuestras necesidades o las de vuestro cliente, es necesario analizar cada caso y estudiar que modelo es más conveniente.
Veamos cuales son las ventajas y desventajas de este modelo:
Ventajas de Domain-Driven Design
- Código bien organizado, permitiendo el testing de las distintas partes del dominio de manera aisladas
- Lógica de negocio reside en un solo lugar y dividida por contextos
- Mantenibilidad a largo plazo
- Comunicación efectiva entre expertos del dominio y expertos técnicos a través de Ubiquitous Language (Lenguaje Ubicuo)
Desventajas de Domain-Driven Design
- Experiencia en el dominio: Domain-Driven Design requiere una amplia experiencia en el dominio. Esto significa que el equipo debería tener al menos un experto en dominio que ayude a definir todos los procesos, procedimientos y terminología de ese dominio
- Costes de desarrollo: el equipo debe implementar una gran cantidad de aislamiento y encapsulación dentro del modelo de dominio. Esto a menudo da como resultado un desarrollo y una duración más prolongados, que pueden tener un costo relativamente alto. Por lo que podemos decir que no es un modelo adecuado para proyectos a corto plazo o proyectos sin una gran complejidad de dominio.