Hispanopedia Wiki
Articulo de referencia

Diseño orientado al dominio

El diseño dirigido por el dominio ( DDD ) es un enfoque de diseño de software [ 1 ] que se centra en modelar el software para que se ajuste a un dominio según la información pro...

Hispanopedia WikiContenido en espanolLectura gratuita

El diseño dirigido por el dominio ( DDD ) es un enfoque de diseño de software [ 1 ] que se centra en modelar el software para que se ajuste a un dominio según la información proporcionada por los expertos de ese dominio. [ 2 ] El DDD se opone a la idea de tener un único modelo unificado; en su lugar, divide un sistema grande en contextos delimitados, cada uno de los cuales tiene su propio modelo. [ 3 ] [ 4 ]

En el diseño orientado al dominio, la estructura y el lenguaje del código de software (nombres de clases, métodos de clase , variables de clase ) deben coincidir con el dominio de 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 orientado al dominio se basa en los siguientes objetivos:

  • centrando el proyecto principalmente en el dominio central y la capa de lógica de dominio;
  • basar diseños complejos en un modelo del dominio;
  • Iniciar una colaboración creativa entre expertos técnicos y especialistas en el dominio para refinar de forma iterativa un modelo conceptual que aborde problemas específicos del dominio.

Los críticos del diseño dirigido por el dominio argumentan que los desarrolladores suelen tener que 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 dirigido por el dominio ofrece ventajas como la mantenibilidad, Microsoft lo recomienda únicamente para dominios complejos donde el modelo proporciona beneficios claros para formular una comprensión común del dominio. [ 5 ]

El término fue acuñado por Eric Evans en su libro del mismo nombre publicado en 2003. [ 3 ]

Descripción general

El diseño orientado al dominio articula una serie de conceptos y prácticas de alto nivel. [ 3 ]

De suma importancia es el dominio del software, el área temática a la que el usuario aplica un programa. Los desarrolladores de software crean 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 orientado al dominio buscan fomentar un lenguaje común compartido por expertos en el dominio, usuarios y desarrolladores: el lenguaje ubicuo . Este lenguaje 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 orientado al dominio, la capa de dominio es una de las capas comunes en una arquitectura multicapa orientada a objetos .

Tipos de modelos

El diseño orientado al dominio reconoce varios tipos de modelos. Por ejemplo, una entidad es un objeto definido no por sus atributos, sino por su identidad . Como ejemplo, la mayoría de las aerolíneas asignan un número único a los asientos de cada vuelo: esta es la identidad del asiento. En cambio, un objeto de valor es un objeto inmutable que contiene atributos pero carece de identidad conceptual. Cuando las personas intercambian tarjetas de visita, por ejemplo, solo les interesa la información que contiene la tarjeta (sus atributos) en lugar de intentar distinguir entre cada tarjeta única.

Los modelos también pueden definir eventos (algo que sucedió en el pasado). Un evento de dominio es un evento que interesa a los expertos del dominio. Los modelos pueden vincularse mediante una entidad raíz para formar un agregado . Los objetos fuera del agregado pueden contener referencias a la raíz, pero no a ningún otro objeto del agregado. La raíz del agregado verifica la coherencia de los cambios en el mismo. Por ejemplo, los conductores no tienen que controlar individualmente cada rueda de un automóvil: simplemente lo conducen. En este contexto, un automóvil es un agregado de varios otros objetos (el motor, los frenos, los faros, etc.).

Trabajar con modelos

En el diseño orientado al dominio, la creación de un objeto a menudo se separa del objeto en sí.

Un repositorio , por ejemplo, es un objeto con métodos para recuperar objetos de dominio de un almacén de datos (por ejemplo, una base de datos). Del mismo modo, una fábrica es un objeto con métodos para crear directamente objetos de dominio.

Cuando parte de la funcionalidad de un programa no pertenece conceptualmente a ningún objeto, normalmente se expresa como un servicio .

Tipos de eventos

En DDD existen diferentes tipos de eventos , y las opiniones sobre su clasificación pueden variar. Según Yan Cui, existen dos categorías clave de eventos: [ 6 ]

Eventos de dominio

Los eventos de dominio indican sucesos importantes dentro de un dominio empresarial específico. Estos eventos están restringidos a un contexto delimitado y son vitales para preservar la lógica empresarial. Por lo general, los eventos de dominio tienen cargas útiles más ligeras , que contienen solo la información necesaria para su procesamiento. Esto se debe a que los oyentes de eventos suelen estar dentro del mismo servicio, donde sus requisitos se comprenden con mayor claridad. [ 6 ]

Eventos de integración

Por otro lado, los eventos de integración sirven para comunicar cambios entre diferentes contextos delimitados. Son cruciales para garantizar la coherencia de los datos en todo el sistema. Los eventos de integración suelen tener cargas útiles más complejas con atributos adicionales , ya que las necesidades de los posibles receptores pueden diferir significativamente. Esto a menudo conlleva un enfoque más exhaustivo de la comunicación, lo que resulta en una comunicación excesiva para garantizar que toda la información relevante se comparta de manera efectiva. [ 6 ]

Patrones de mapeo de contexto

El mapeo de contexto identifica y define los límites de diferentes dominios o subdominios dentro de un sistema más amplio. Ayuda a visualizar cómo interactúan y se relacionan entre sí estos contextos. A continuación se muestran algunos patrones, según Eric Evans: [ 7 ]

  • Asociación: "forjar una asociación entre los equipos a cargo de los dos contextos. Instituir un proceso para la planificación coordinada del desarrollo y la gestión conjunta de la integración" , cuando "los equipos en dos contextos tendrán éxito o fracasarán juntos".
  • Núcleo compartido: "Designa con un límite explícito un subconjunto del modelo de dominio que los equipos acuerden compartir. Mantén este núcleo pequeño."
  • Desarrollo de clientes/proveedores: "Establecer una relación clara entre clientes y proveedores entre los dos equipos" , cuando "dos equipos están en una relación ascendente-descendente".
  • Conformista: "Eliminar la complejidad de la traducción [...] elegir la conformidad simplifica enormemente la integración" , cuando no es probable que se cree una interfaz personalizada para un subsistema posterior.
  • Capa anticorrupción: "crea una capa aislante para proporcionar a tu sistema la funcionalidad del sistema anterior en términos de tu propio modelo de dominio".
  • Servicio de host abierto: "un protocolo que da acceso a su subsistema como un conjunto de servicios" , en caso de que sea necesario integrar un subsistema con muchos otros, lo que hace inviable la realización de traducciones personalizadas entre subsistemas.
  • Lenguaje publicado: "un lenguaje compartido bien documentado que puede expresar la información necesaria del dominio 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 sencillas y especializadas dentro de este pequeño ámbito".
  • Gran bola de lodo: [ 8 ] "un límite alrededor de todo el desastre" cuando no se pueden encontrar límites reales al inspeccionar un sistema existente.

Relación con otras ideas

Si bien el diseño orientado al dominio no está intrínsecamente ligado a los enfoques orientados a objetos , en la práctica aprovecha las ventajas de dichas técnicas. Estas incluyen entidades/raíces agregadas como receptoras de comandos/invocaciones de métodos, la encapsulación del estado dentro de las raíces agregadas principales y, a un nivel arquitectónico superior, contextos delimitados.

Como resultado, el diseño orientado al dominio suele asociarse con los objetos Java simples (Plain Old Java Objects) y los objetos CLR simples (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 cada vez más extendida de que los objetos de dominio deben definirse exclusivamente por el comportamiento empresarial del dominio, en lugar de por un marco tecnológico más específico.

De manera similar, el patrón de objetos desnudos 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 obligará al diseño de un mejor modelo de dominio. [ 9 ]

El diseño orientado al dominio ha influido en otros enfoques del desarrollo de software.

El modelado específico de dominio , por ejemplo, es un diseño orientado al dominio aplicado con lenguajes específicos de dominio . El diseño orientado al dominio no requiere específicamente el uso de un lenguaje específico de dominio, aunque podría utilizarse para ayudar a definir un lenguaje específico de dominio y para dar soporte al multimodelado específico de dominio .

A su vez, la programación orientada a aspectos facilita la exclusión de aspectos técnicos (como la seguridad, la gestión de transacciones y el registro de eventos) de un modelo de dominio, lo que permite centrarse exclusivamente en la lógica de negocio.

Ingeniería y arquitectura basadas en modelos

Si bien el diseño dirigido por el dominio es compatible con la ingeniería dirigida por modelos y la arquitectura dirigida por modelos , [ 10 ] 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 diferentes plataformas tecnológicas que por definir mejores modelos de dominio.

Sin embargo, las técnicas que ofrece la ingeniería dirigida por modelos (para modelar dominios, crear lenguajes específicos de dominio para facilitar la comunicación entre expertos en el dominio y desarrolladores, etc.) facilitan el diseño dirigido por el dominio en la práctica y ayudan a los profesionales a sacar más provecho 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á. [ 11 ]

Segregación de responsabilidades de comandos y consultas

La segregación de responsabilidades de comandos y consultas (CQRS, por sus siglas en inglés) es un patrón arquitectónico para separar la lectura de datos (una "consulta") de la escritura de datos (un "comando"). CQRS deriva de la separación de comandos y consultas (CQS, por sus siglas en inglés), término acuñado por Bertrand Meyer .

Los comandos modifican el estado y son aproximadamente equivalentes a la invocación de métodos en raíces o entidades agregadas. Las consultas leen el estado, pero no lo modifican.

Si bien CQRS no requiere un diseño orientado al dominio, hace explícita la distinción entre comandos y consultas mediante el concepto de raíz agregada. La idea es que una raíz agregada determinada tiene un método que corresponde a un comando, y un manejador de comandos invoca dicho método en la raíz agregada.

La raíz del agregado se encarga de ejecutar la lógica de la operación y de generar una respuesta de error o simplemente modificar su propio estado para escribirlo en un almacén de datos. El gestor de comandos incorpora aspectos de infraestructura relacionados con el guardado del estado de la raíz del agregado y la creación de los contextos necesarios (por ejemplo, transacciones).

Tormenta de eventos

Event Storming es una técnica de modelado colaborativa, basada en talleres, que puede utilizarse como precursora en el contexto del Diseño Orientado al Dominio (DDD) para identificar y comprender los eventos del dominio. Este proceso de descubrimiento interactivo involucra a las partes interesadas, expertos del dominio y desarrolladores que trabajan juntos para visualizar el flujo de los eventos del dominio, sus causas y sus efectos, fomentando una comprensión compartida del dominio. La técnica suele utilizar notas adhesivas codificadas por colores para representar diferentes elementos, como eventos del dominio, agregados y sistemas externos, facilitando 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 descubrir 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 de negocio. [ 12 ] [ 13 ]

Búsqueda de proveedores para eventos

El event sourcing es un patrón arquitectónico en el que las entidades rastrean su estado interno no mediante serialización directa o mapeo objeto-relacional, sino leyendo y registrando eventos en un almacén de eventos .

Cuando se combina el enfoque de origen de eventos con CQRS y el diseño orientado al dominio, las raíces de agregación se encargan de validar y aplicar comandos (a menudo mediante la invocación de sus métodos de instancia desde un controlador de comandos) y, posteriormente, de publicar eventos. Esta es también la base sobre la que las raíces de agregación fundamentan su lógica para gestionar las invocaciones de métodos. Por lo tanto, 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 intermediario de mensajes para los interesados ​​(como la vista de una aplicación ).

Modelar raíces agregadas para generar eventos puede aislar el estado interno aún más que cuando se proyectan datos de lectura desde entidades, como en las arquitecturas estándar de paso de datos de n niveles. Una ventaja significativa es que los demostradores de teoremas axiomáticos (por ejemplo, Microsoft Contracts y CHESS [ 14 ] ) son más fáciles de aplicar, ya que la raíz agregada oculta completamente su estado interno. Los eventos a menudo se persisten en función de la versión de la instancia de la raíz agregada, lo que produce un modelo de dominio que se sincroniza en sistemas distribuidos a través de la concurrencia optimista .

Mapeo de contextos delimitados a microservicios

Un contexto delimitado, concepto fundamental en el Diseño Orientado al Dominio (DDD), define un área específica dentro de la cual un modelo de dominio es consistente y válido, garantizando claridad y separación de responsabilidades. [ 15 ] En la arquitectura de microservicios , un contexto delimitado suele corresponder a un microservicio, pero esta relación puede variar según el enfoque de diseño. Una relación uno a uno, donde cada contexto delimitado se implementa como un único microservicio, suele ser ideal, ya que mantiene límites claros, reduce el acoplamiento y permite el despliegue y escalado independientes. Sin embargo, otras asignaciones también pueden ser apropiadas: una relación uno a muchos puede surgir cuando un contexto delimitado se divide en múltiples microservicios para abordar diferentes necesidades de escalabilidad u otras necesidades operativas, mientras que una relación muchos a uno puede consolidar múltiples contextos delimitados en un único microservicio para simplificar o minimizar la sobrecarga operativa. La elección de la relación debe equilibrar los principios del DDD con los objetivos de negocio del sistema, las restricciones técnicas y los requisitos operativos. [ 16 ]

Herramientas destacadas

Aunque el diseño orientado al dominio no depende de ninguna herramienta o marco de trabajo en particular, algunos ejemplos notables incluyen:

  • Actifsource , un complemento para Eclipse que permite el desarrollo de software combinando DDD con ingeniería dirigida por modelos y generación de código .
  • Context Mapper, un lenguaje y herramientas específicas de dominio para DDD estratégico y táctico. [ 17 ]
  • CubicWeb es un framework web semántico de código abierto, totalmente basado en un modelo de datos. Las directivas de alto nivel permiten refinar el modelo de datos de forma iterativa, versión tras versión. Basta con definir el modelo de datos para obtener una aplicación web funcional. Se requiere trabajo adicional para definir cómo se muestran los datos cuando las vistas predeterminadas no son suficientes.
  • OpenMDX es un marco de trabajo MDA de código abierto basado en Java que admite Java SE , Java EE y .NET . OpenMDX se diferencia de los marcos de trabajo MDA típicos en que "utiliza modelos para controlar directamente el comportamiento en tiempo de ejecución de los sistemas operativos" .
  • Restful Objects es un estándar para mapear una API RESTful a un modelo de objetos de dominio (donde los objetos de dominio pueden representar entidades, modelos de vista o servicios). Dos marcos de código abierto (uno para Java y otro para .NET) pueden crear una API Restful Objects a partir de un modelo de dominio automáticamente, utilizando reflexión .

Véase también

Referencias

  1. ↑ Millet, Scott; Tune, Nick (2015). Patrones, principios y prácticas del diseño orientado al dominio . Indianápolis: Wrox. ISBN 978-1-118-71470-6.
  2. ↑ Vernon, Vaughn (2013). Implementing Domain-Driven Design . Upper Sadle River, NJ: Addison-Wesley. p. 3. ISBN  978-0-321-83457-7.
  3. 1 2 3 Evans, Eric (22 de agosto de 2003). Diseño orientado al dominio: Abordando la complejidad en el corazón del software . Boston: Addison-Wesley. ISBN 978-032-112521-7. Consultado el 12 de agosto de 2012 .
  4. ↑ martinekuan. "Uso de DDD táctico para diseñar microservicios - Centro de arquitectura de Azure" . learn.microsoft.com . Consultado el 7 de septiembre de 2024 .
  5. ↑ Guía de arquitectura de aplicaciones de Microsoft, 2.ª edición. Obtenido de http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle .
  6. 1 2 3 Cui, Yan. Arquitecturas sin servidor en AWS . Manning. ISBN 978-1617295423.
  7. ↑ Evans, Eric. Referencia de diseño orientado al dominio: definiciones y resúmenes de patrones . ISBN 978-1457501197.
  8. ↑ Foote, Brian; Yoder, Joseph (1999), Big Ball of Mud , consultado el 9 de mayo de 2025
  9. ↑ Haywood, Dan (2009), Diseño orientado al dominio mediante objetos desnudos , Pragmatic Programmers.
  10. ↑ MDE puede considerarse un superconjunto de MDA
  11. ↑ Cabot, Jordi (11 de septiembre de 2017). "Comparación entre el diseño orientado al dominio y la ingeniería orientada a modelos" . Modeling Languages . Consultado el 5 de agosto de 2021 .
  12. ↑ Aprendiendo Diseño Orientado al Dominio: Alineando la Arquitectura de Software y la Estrategia Empresarial . ISBN 978-1098100131.
  13. ↑ Open Agile Architecture™ - Un estándar de The Open Group . ISBN 9789401807265.
  14. ↑ una herramienta de detección de errores de Microsoft
  15. ↑ Fundamentos de la arquitectura de software: Un enfoque de ingeniería . O'Reilly Media. 2020. ISBN 978-1492043454.
  16. ↑ Creación de microservicios por Sam Newman . ISBN 978-1492034025.
  17. ↑ Stefan Kapferer y Olaf Zimmermann: Diseño de servicios orientado al dominio: modelado de contexto, refactorización de modelos y generación de contratos, 14.º Simposio y Escuela de Verano sobre Computación Orientada a Servicios (SommerSoC 2020)
  • Diseño orientado al dominio, definiciones y resúmenes de patrones (PDF) , Eric Evans, 2015
  • Equipo DDD en GitHub : Bounded Context Canvas, Aggregate Canvas, Modeling Process y más repositorios.
  • Introducción al diseño orientado a dominios , métodos y herramientas.
  • Implementación de raíz agregada en lenguaje C#
  • Context Mapper: Un marco de modelado para el diseño estratégico orientado al dominio (Herramienta, tutoriales, ejemplos de modelado DDD)
  • Actividad estratégica de DDC en el repositorio de prácticas de diseño (DPR) y actividad táctica de DDC en el repositorio de prácticas de diseño (DPR)