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.
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.
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.
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:
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.
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.
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.
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.
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: