Domain-Driven Design: Patrones estratégicos

Domain-Driven Design (DDD), o diseño basado en dominios, es una filosofía de desarrollo definida por Eric Evans en su libro 'Domain-Driven Desing: Tackling Complexity in the Heart of Software' publicado en 2003. Diseñada para la creación y mantenimiento de software escrito para manejar problemas de dominios complejos, DDD pone el énfasis en la necesidad de enfocarse en el dominio del problema empresarial, su terminología, las razones principales por la que se desarrolla el software, y que se espera del desarrollo de la aplicación.

DDD se ocupa tanto del desafío de comprender el problema de un dominio como de crear una solución mantenible que sea útil para resolver problemas dentro de él. El lenguaje común, la colaboración con los expertos del dominio y el contexto, se consideran las facetas más importantes del DDD.  

El diseño basado en dominios es un enfoque para el desarrollo de software complejo en el que:

  1. El foco es el dominio principal
  2. Se exploran modelos en una colaboración creativa entre los profesionales del dominio y los profesionales del desarrollo
  3. Se habla un idioma ubicuo dentro de un contexto delimitado explícito
Eric Evans - Domian-Driven Design Reference

Arquitectura DDD

La arquitectura de software que se usa habitualmente cuando se utiliza el paradigma DDD difiere de la tradicional arquitectura de tres capas:

Arquitectura DDD

Las cuatro capas de la arquitectura DDD representan:

  • Capa Presentación: Es el Interfaz de usuario, responsable de presentar e interactuar con la información del usuario
  • Capa de Aplicación: Coordina la actividad de la aplicación. No contiene ninguna lógica empresarial, ni estado de los objetos comerciales, pero puede contener el estado del progreso de una tarea de aplicación
  • Capa de Dominio: Contiene información sobre el dominio empresarial. El estado de los objetos comerciales se mantiene aquí
  • Capa de Infraestructura: Actúa como una biblioteca de apoyo para todas las demás capas. Proporciona comunicación entre capas, implementa persistencia para objetos comerciales, contiene bibliotecas de soporte para la capa de interfaz de usuario, etc.

Dentro de DDD encontramos muchos conceptos y patrones. Estos se pueden dividir en dos tipos:

  • Patrones estratégicos: Destilan el problema del dominio y dan forma a la arquitectura de la solución. Van a definir como se comunican e interactúan los desarrolladores con los expertos del dominio, un idioma común que emplear, limites de contexto, mapas de contextos e interrelaciones, y en general todas las cuestiones que no no atañen directamente al código de la aplicación
  • Patrones tácticos: También conocidos como bloques de construcción de modelos, son los patrones que atañen a todo lo referente al código de la solución y se utilizan para implementar modelos efectivos para contextos delimitados complejos.

Patrones estratégicos

Destilar problema - Idioma ubicuo - Modelo de dominio - Contexto delimitado

 

Patrones Estratégicos

Destilar el problema

Los desarrolladores y los expertos del dominio tienen que analizar en profundidad el problema presentado. El objetivo es destilar el problema del dominio para encontarar que es lo más importante, revelando el dominio central (core domain). De esta forma, un domino se puede dividir en subdominios más manejables. En DDD se enfatiza la necesidad de enfocar los esfuerzos en el dominio central, que es el motivo fundamental del desarrollo y permite identificar los objetivos y saber cuando se han alcanzado de forma satisfactoria.

Idioma ubicuo

Con el fin de establecer un mejor entendimiento, los desarrolladores y los expertos del dominio necesitan una comunicación efectiva. Se tiene que establecer, dentro de un contexto delimitado, un idioma ubicuo (ubiquitous language) (UL), que permite establecer la colaboración entre los desarrolladores y los expertos del dominio. El idioma ubicuo es un idioma común, un idioma que permite explicar cada parte del dominio así como sus problemas, entendible por todos y sin ambigüedad en sus términos. La creación de un idioma ubicuo permite un profundo entendimiento durante toda la vida del proyecto. 

Modelo de dominio

Un modelo de dominio no es un diagrama particular; es la idea que el diagrama pretende transmitir. No es solo el conocimiento en la cabeza de un experto en el dominio; es una abstracción rigurosamente organizada y selectiva de ese conocimiento

Eric Evans - Domian-Driven Design: Tackling Complexity in the Heart of Software

Para una comprensión profunda del problema del domino se utilizan los modelos de dominio como parte central del DDD. El modelo de dominio explica cómo se ha capturado la comprensión esencial del negocio en cuestión como un conjunto seleccionado de conceptos. Los modelos de dominio no son modelos de la vida real, estos son un sistema de abstracciones de la realidad, una interpretación que solo incluye aspectos de los problemas del dominio que prevalecen para resolver casos específicos y excluyen detalles irrelevantes del dominio.

Contexto delimitado

Al igual que el idioma ubicuo el modelo de dominio tiene que tener un contexto delimitado para mantener su integridad. Dentro de este contexto no tiene que existir ambigüedad en la terminología. Un problema de un domino puede dividirse en subdominios para un mejor entendimiento y se creará un modelo para cada uno de los subdominios. En proyectos grandes, cuando un modelo no pueda mantener su integridad, existirán diferentes contextos, con diferentes modelos que responderán a problemas diferentes de un sistema complejo.

Integración continua

Cada vez que se realiza un cambio tiene que integrarse en el conjunto. Todo el trabajo dentro del contexto se tiene que fusionar, testear y hacer consistente con la frecuencia suficiente de tal forma que si se produce un fragmento que no mantenga la coherencia del proyecto este se detecte y corrija lo más rápidamente posible.

Mapa de contexto

En aplicaciones largas y complejas múltiples contextos tienen que colaborar entre ellos. Para reducir la confusión se puede definir las relaciones entre los diferentes contextos y crear una vista global de todos los contextos de modelos en el proyecto. Tenemos que tener en cuenta que estamos en los patrones estratégicos, es decir no se trata los aspectos técnicos de integración en el código sino como se interrelacionan los modelos y los equipos. En las relaciones entre contextos podemos encontrar los siguientes patrones:

Mapa de Contexto

Conclusión

Como filosofía de creación y mantenimiento de software, DDD pone un énfasis especial en el análisis, el enfoque en el dominio principal y la comunicación y colaboración entre los desarrolladores y los expertos del dominio. Conforme van siendo los desarrollos más complejos, más relevantes se muestran estos patrones estratégicos.

Extendiendo conceptos y aplicando los patrones del DDD se han desarrollado prácticas y estrategias destinadas a mejorar la seguridad de las aplicaciones, tratando la seguridad como una cualidad del diseño de la aplicación y no como una característica a añadir posteriormente, lo que se ha mostrado muy efectivo a la hora de reducir las vulnerabilidades resultantes en el código

Por otro lado, DDD es independiente del lenguaje de programación elegido, no requiere el uso de ningún frameware o base de datos especial, ni impone el uso de una arquitectura especifica para el desarrollo. Una metodología orientada a objetos es útil para construir los modelos, aunque tampoco es un requerimiento obligatorio.

Con el fin de expresar en código e implementar correctamente los modelos de dominio, se utilizan los patrones tácticos o bloques de construcción de modelos. Estos los veremos próximamente.

Modificado por última vez enMiércoles, 21 Octubre 2020 16:15
(2 votos)
Etiquetado como :

Más en esta categoría:

« Patrones de diseño - Estrategia

Deja un comentario

Asegúrese de introducir toda la información requerida, indicada por un asterisco (*). No se permite código HTML.