El diseño guiado por el dominio (Domain-driven design o DDD) es un enfoque de diseño de software que se centra en modelar el software para que coincida con un dominio según la información proporcionada por los expertos de dicho dominio. DDD se opone a la idea de tener un único modelo unificado; en su lugar, divide un sistema grande en contextos delimitados (bounded contexts), cada uno de los cuales tiene su propio modelo.
Bajo el diseño guiado por el dominio, la estructura y el lenguaje del código del software (nombres de clases, métodos de clase, variables de clase) deben coincidir con el dominio del negocio. Por ejemplo, si el software procesa solicitudes de préstamos, podría tener clases como “solicitud de préstamo”, “clientes”, y métodos como “aceptar oferta” y “retirar”.
El diseño guiado por el dominio se basa en los siguientes objetivos:
Situar el foco principal del proyecto en el dominio central y en la capa de lógica de dominio; Basar los diseños complejos en un modelo del dominio; Iniciar una colaboración creativa entre expertos técnicos y expertos del dominio para refinar iterativamente un modelo conceptual que aborde problemas específicos del dominio.
Los críticos del diseño guiado por el dominio argumentan que los desarrolladores normalmente deben implementar un alto grado de aislamiento y encapsulación para mantener el modelo como una construcción pura y útil. Si bien el diseño guiado por el dominio proporciona beneficios como la mantenibilidad, Microsoft recomienda su uso únicamente para dominios complejos en los que el modelo aporta beneficios claros a la hora de formular una comprensión común del dominio.Microsoft Application Architecture Guide, 2nd Edition. Retrieved from https://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle .
El término fue acuñado por Eric Evans en su libro homónimo publicado en 2003.
Visión general El diseño guiado por el dominio articula una serie de conceptos y prácticas de alto nivel.
De importancia primordial es el dominio del software, el área temática a la que el usuario aplica un programa. Los desarrolladores del software construyen un modelo de dominio: un sistema de abstracciones que describe aspectos seleccionados de un dominio y que puede utilizarse para resolver problemas relacionados con dicho dominio.
Estos aspectos del diseño guiado por el dominio buscan fomentar un lenguaje común compartido por expertos del dominio, usuarios y desarrolladores: el lenguaje ubicuo (ubiquitous language). El lenguaje ubicuo se utiliza en el modelo de dominio y para describir los requisitos del sistema.
El lenguaje ubicuo es uno de los pilares de DDD junto con el diseño estratégico y el diseño táctico.
En el diseño guiado por el dominio, la capa de dominio es una de las capas comunes en una arquitectura orientada a objetos multicapa.
Trabajo con modelos En el diseño guiado por el dominio, la creación de un objeto suele separarse del propio objeto.
Un repositorio, por ejemplo, es un objeto con métodos para recuperar objetos de dominio desde un almacén de datos (por ejemplo, una base de datos). De manera similar, una fábrica es un objeto con métodos para crear directamente objetos de dominio.
Cuando una parte de la funcionalidad de un programa no pertenece conceptualmente a ningún objeto, normalmente se expresa como un servicio.
Tipos de eventos Existen distintos tipos de eventos en DDD, y las opiniones sobre su clasificación pueden variar. Según Yan Cui, existen dos categorías clave de eventos:
Eventos de dominio Los eventos de dominio representan ocurrencias importantes dentro de un dominio de negocio específico. Estos eventos están restringidos a un contexto delimitado y son vitales para preservar la lógica de negocio. Normalmente, los eventos de dominio tienen cargas útiles más ligeras, que contienen únicamente la información necesaria para su procesamiento. Esto se debe a que los consumidores de eventos suelen estar dentro del mismo servicio, donde sus requisitos se comprenden con mayor claridad.
Eventos de integración Por otro lado, los eventos de integración sirven para comunicar cambios entre distintos contextos delimitados. Son cruciales para garantizar la consistencia de los datos en todo el sistema. Los eventos de integración tienden a tener cargas útiles más complejas con atributos adicionales, ya que las necesidades de los posibles consumidores pueden variar significativamente. Esto suele dar lugar a un enfoque más exhaustivo de la comunicación, resultando en una sobrecomunicación para asegurar que toda la información relevante se comparta de forma efectiva.
Patrones de mapeo de contextos El mapeo de contextos identifica y define los límites de distintos dominios o subdominios dentro de un sistema más grande. Ayuda a visualizar cómo estos contextos interactúan y se relacionan entre sí. A continuación se muestran algunos patrones, según Eric Evans:
Partnership: "forjar una asociación entre los equipos a cargo de los dos contextos. Instituir un proceso de planificación coordinada del desarrollo y gestión conjunta de la integración", cuando "los equipos de ambos contextos tendrán éxito o fracasarán juntos"
Shared Kernel: "designar, con un límite explícito, algún subconjunto del modelo de dominio que los equipos acuerdan compartir. Mantener este núcleo pequeño"
Customer/Supplier Development: "establecer una relación clara de cliente/proveedor entre los dos equipos", cuando "dos equipos están en una relación upstream-downstream"
Conformist: "eliminar la complejidad de la traducción [...] elegir la conformidad simplifica enormemente la integración", cuando no es probable que exista una interfaz personalizada para un subsistema downstream
Anticorruption Layer: "crear una capa de aislamiento que proporcione a tu sistema la funcionalidad del sistema upstream en términos de tu propio modelo de dominio"
Open-host Service: "un protocolo que da acceso a tu subsistema como un conjunto de servicios", en caso de que sea necesario integrar un subsistema con muchos otros, haciendo inviables las traducciones personalizadas entre subsistemas
Published Language: "un lenguaje compartido bien documentado que pueda expresar la información de dominio necesaria como un medio común de comunicación", por ejemplo, estándares de intercambio de datos en diversas industrias
Separate Ways: "un contexto delimitado sin ninguna conexión con los demás, lo que permite a los desarrolladores encontrar soluciones simples y especializadas dentro de este ámbito reducido"
Big Ball of Mud: "un límite alrededor de todo el desorden", cuando no se pueden encontrar límites reales al analizar un sistema existente
Relación con otras ideas Aunque el diseño guiado por el dominio no está inherentemente ligado a los enfoques orientados a objetos, en la práctica aprovecha las ventajas de dichas técnicas. Estas incluyen entidades/raíces de agregado como receptoras de comandos o invocaciones de métodos, la encapsulación del estado dentro de las principales raíces de agregado y, a un nivel arquitectónico superior, los contextos delimitados.
Como resultado, el diseño guiado por el dominio suele asociarse con Plain Old Java Objects y Plain Old CLR Objects, que son detalles técnicos de implementación específicos de Java y del .NET Framework respectivamente. Estos términos reflejan una visión creciente de que los objetos de dominio deben definirse puramente por el comportamiento del negocio del dominio, en lugar de por un framework tecnológico específico.
De forma similar, el patrón de naked objects sostiene que la interfaz de usuario puede ser simplemente un reflejo de un modelo de dominio suficientemente bueno. Exigir que la interfaz de usuario sea un reflejo directo del modelo de dominio obliga al diseño de un mejor modelo de dominio..
El diseño guiado por el dominio ha influido en otros enfoques de desarrollo de software.
El modelado específico del dominio, por ejemplo, es el diseño guiado por el dominio aplicado con lenguajes específicos del dominio. El diseño guiado por el dominio no requiere específicamente el uso de un lenguaje específico del dominio, aunque podría utilizarse para ayudar a definirlo y respaldar el multimodelado específico del dominio.
A su vez, la programación orientada a aspectos facilita la separación de las preocupaciones técnicas (como seguridad, gestión de transacciones y registro de eventos) del modelo de dominio, permitiendo que este se centre exclusivamente en la lógica de negocio.
Ingeniería y arquitectura dirigidas por modelos Aunque el diseño guiado por el dominio es compatible con la ingeniería dirigida por modelos y la arquitectura dirigida por modelos,[https://modeling-languages.com/clarifying-concepts-mbe-vs-mde-vs-mdd-vs-mda/ MDE puede considerarse un superconjunto de MDA] la intención detrás de ambos conceptos es diferente. La arquitectura dirigida por modelos se preocupa más por traducir un modelo a código para distintas plataformas tecnológicas que por definir mejores modelos de dominio.
Sin embargo, las técnicas proporcionadas por la ingeniería dirigida por modelos (para modelar dominios, crear lenguajes específicos del dominio que faciliten la comunicación entre expertos del dominio y desarrolladores, etc.) facilitan el diseño guiado por el dominio en la práctica y ayudan a los profesionales a obtener más valor de sus modelos. Gracias a las técnicas de transformación de modelos y generación de código de la ingeniería dirigida por modelos, el modelo de dominio puede utilizarse para generar el sistema de software real que lo gestionará.
Event storming Event storming es una técnica de modelado colaborativa, basada en talleres, que puede utilizarse como paso previo en el contexto del Diseño Guiado por el Dominio (DDD) para identificar y comprender eventos de dominio. Este proceso interactivo de descubrimiento involucra a las partes interesadas, expertos del dominio y desarrolladores que trabajan juntos para visualizar el flujo de eventos del dominio, sus causas y efectos, fomentando una comprensión compartida del dominio. La técnica suele utilizar notas adhesivas codificadas por colores para representar distintos elementos, como eventos de dominio, agregados y sistemas externos, lo que facilita una exploración clara y estructurada del dominio. Event storming puede ayudar a descubrir subdominios, contextos delimitados y límites de agregados, que son construcciones clave en DDD. Al centrarse en “qué sucede” en el dominio, la técnica puede ayudar a revelar procesos de negocio, dependencias e interacciones, proporcionando una base para implementar los principios de DDD y alinear el diseño del sistema con los objetivos del negocio.
Event sourcing El event sourcing es un patrón arquitectónico en el que las entidades registran su estado interno no mediante serialización directa o mapeo objeto-relacional, sino leyendo y registrando eventos en un almacén de eventos.
Cuando el event sourcing se combina con CQRS y el diseño guiado por el dominio, las raíces de agregado son responsables de validar y aplicar comandos (a menudo mediante la invocación de métodos de instancia desde un manejador de comandos) y luego publicar eventos. Esta es también la base sobre la cual las raíces de agregado sustentan su lógica para gestionar las invocaciones de métodos. De este modo, la entrada es un comando y la salida es uno o varios eventos que se guardan en un almacén de eventos y, a menudo, se publican en un message broker para los interesados (como el modelo-vista-controlador).