Domain Driven Design es una metodología y prescripción de procesos para el desarrollo de sistemas complejos cuyo enfoque es mapear actividades, tareas, eventos y datos dentro de un dominio problemático en los artefactos tecnológicos de un dominio de solución.
El énfasis del diseño impulsado por dominio es comprender el dominio del problema para crear un modelo abstracto del dominio del problema que luego puede implementarse en un conjunto particular de tecnologías. El diseño impulsado por dominio como metodología proporciona pautas sobre cómo este desarrollo de modelo y desarrollo de tecnología puede dar como resultado un sistema que satisfaga las necesidades de las personas que lo utilizan y, al mismo tiempo, sea robusto frente al cambio en el dominio del problema.
El lado del proceso del diseño dirigido por el dominio implica la colaboración entre expertos en el dominio, personas que conocen el dominio del problema y los expertos en diseño / arquitectura, personas que conocen el dominio de la solución. La idea es tener un modelo compartido con un lenguaje compartido para que las personas de estos dos dominios diferentes con sus dos perspectivas diferentes discutan la solución, en realidad están discutiendo una base de conocimiento compartida con conceptos compartidos.
La falta de una comprensión del dominio del problema compartido entre las personas que necesitan un sistema en particular y las personas que están diseñando e implementando el sistema parece ser un impedimento central para proyectos exitosos. El diseño impulsado por dominio es una metodología para abordar este impedimento.
Es más que tener un modelo de objetos. El enfoque es realmente sobre la comunicación compartida y la mejora de la colaboración para que se puedan descubrir las necesidades reales dentro del dominio del problema y se cree una solución adecuada para satisfacer esas necesidades.
Diseño impulsado por dominio: lo bueno y lo desafiante proporciona una breve descripción general con este comentario:
DDD ayuda a descubrir la arquitectura de nivel superior e informar sobre la mecánica y la dinámica del dominio que el software necesita para replicarse. Concretamente, significa que un análisis DDD bien hecho minimiza los malentendidos entre los expertos en dominios y los arquitectos de software, y reduce el número subsiguiente de costosas solicitudes de cambio. Al dividir la complejidad del dominio en contextos más pequeños, DDD evita obligar a los arquitectos de proyectos a diseñar un modelo de objetos hinchados, que es donde se pierde mucho tiempo resolviendo los detalles de la implementación, en parte porque la cantidad de entidades con las que lidiar a menudo crece más allá de tamaño de las pizarras de la sala de conferencias.
Consulte también este artículo Diseño impulsado por dominio para la arquitectura de servicios que proporciona un breve ejemplo. El artículo proporciona la siguiente descripción en miniatura del diseño controlado por dominio.
Domain Driven Design aboga por el modelado basado en la realidad de los negocios como relevante para nuestros casos de uso. Como ahora se está volviendo más viejo y el nivel de exageración está disminuyendo, muchos de nosotros olvidamos que el enfoque DDD realmente ayuda a comprender el problema en cuestión y a diseñar el software hacia la comprensión común de la solución. Al crear aplicaciones, DDD habla de problemas como dominios y subdominios. Describe pasos / áreas de problemas independientes como contextos limitados, enfatiza un lenguaje común para hablar sobre estos problemas y agrega muchos conceptos técnicos, como entidades, objetos de valor y reglas raíz agregadas para apoyar la implementación.
Martin Fowler ha escrito una serie de artículos en los que se menciona el diseño impulsado por dominio como metodología. Por ejemplo, este artículo, BoundedContext , proporciona una descripción general del concepto de contexto acotado del Desarrollo dirigido por dominio.
En aquellos días más jóvenes, nos aconsejaron construir un modelo unificado de todo el negocio, pero DDD reconoce que hemos aprendido que "la unificación total del modelo de dominio para un sistema grande no será factible ni rentable" 1 . Entonces, en cambio, DDD divide un sistema grande en Contextos delimitados, cada uno de los cuales puede tener un modelo unificado, esencialmente una forma de estructurar Múltiples Modelos Canónicos.