Diseño impulsado por dominio

El diseño impulsado por el dominio ( DDD ) es un enfoque importante de diseño de software , ^[1] que se centra en modelar el software para que se adapte a un dominio según los aportes de los expertos de ese dominio. ^[2] El DDD se opone a la idea de tener un único modelo unificado; en cambio, 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 clase, métodos de clase , variables de clase ) deben coincidir con el dominio empresarial. 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 impulsado por el dominio se basa en los siguientes objetivos:

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

Los críticos del diseño basado en dominios argumentan que los desarrolladores normalmente deben implementar un alto grado de aislamiento y encapsulamiento para mantener el modelo como una construcción pura y útil. Si bien el diseño basado en dominios ofrece ventajas como la facilidad de mantenimiento, Microsoft lo recomienda solo para dominios complejos en los que el modelo ofrece ventajas claras a la hora de 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. ^[6]

El diseño impulsado por el dominio articula una serie de conceptos y prácticas de alto nivel. ^[6]

De importancia primordial es el dominio del software, el área temática a la que el usuario aplica un programa. Los desarrolladores de software construyen un modelo de dominio : un sistema de abstracciones que describe aspectos seleccionados de un dominio y puede utilizarse para resolver problemas relacionados con ese dominio.

Estos aspectos del diseño orientado al dominio tienen como objetivo fomentar un lenguaje común compartido por expertos en el dominio, usuarios y desarrolladores: el lenguaje ubicuo . 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 del DDD junto con el diseño estratégico y el diseño táctico .

En el diseño impulsado por el dominio, la capa de dominio es una de las capas comunes en una arquitectura multicapa orientada a objetos .

El diseño orientado al dominio reconoce múltiples tipos de modelos. Por ejemplo, una entidad es un objeto definido no por sus atributos, sino por su identidad . Por 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. Por el contrario, un objeto de valor es un objeto inmutable que contiene atributos pero no tiene identidad conceptual. Cuando las personas intercambian tarjetas de presentación, por ejemplo, solo se preocupan por la información de la tarjeta (sus atributos) en lugar de tratar de 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 estar unidos por una entidad raíz para convertirse en 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 consistencia de los cambios en el agregado. Los conductores no tienen que controlar individualmente cada rueda de un automóvil, por ejemplo: simplemente conducen el automóvil. En este contexto, un automóvil es un agregado de varios otros objetos (el motor, los frenos, los faros, etc.).

En el diseño impulsado por el dominio, la creación de un objeto a menudo está separada 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). De manera similar, 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 .

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: ^[7]

Los eventos de dominio significan sucesos importantes dentro de un dominio empresarial específico. Estos eventos están restringidos a un contexto limitado y son vitales para preservar la lógica empresarial. Por lo general, los eventos de dominio tienen cargas útiles más livianas , que contienen solo la información necesaria para el procesamiento. Esto se debe a que los oyentes de eventos generalmente están dentro del mismo servicio, donde sus requisitos se entienden más claramente. ^[7]

Por otra parte, los eventos de integración sirven para comunicar cambios en diferentes contextos delimitados. Son cruciales para garantizar la coherencia 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 oyentes pueden diferir significativamente. Esto a menudo conduce a un enfoque más exhaustivo de la comunicación, lo que da como resultado una sobrecomunicación para garantizar que toda la información relevante se comparta de manera efectiva. ^[7]

El mapeo de contexto identifica y define los límites de diferentes 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 presentan algunos patrones, según Eric Evans: ^[8]

• "Asociación"
• "Núcleo compartido"
• "Desarrollo de clientes y proveedores"
• "Conformista"
• Capa anticorrupción
• "Servicio de host abierto"
• "Lenguaje publicado"
• "Caminos separados"
• "Gran bola de barro"

Aunque el diseño orientado al dominio no está inherentemente ligado a los enfoques orientados a objetos , en la práctica, explota las ventajas de dichas técnicas, entre ellas, las entidades o raíces agregadas como receptores de comandos o invocaciones de métodos, la encapsulación del estado dentro de las raíces agregadas más importantes y, en un nivel arquitectónico superior, los contextos delimitados.

Como resultado, el diseño impulsado por el dominio a menudo se asocia con objetos Java simples y objetos CLR simples , que son detalles de implementación técnica, específicos de Java y .NET Framework respectivamente. Estos términos reflejan una visión creciente de que los objetos de dominio deben definirse puramente 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 modelo de dominio mejor. ^[9]

El diseño impulsado por el dominio ha influido en otros enfoques del desarrollo de software.

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

A su vez, la programación orientada a aspectos facilita la eliminación de preocupaciones técnicas (como seguridad, gestión de transacciones, registro) de un modelo de dominio, lo que les permite centrarse exclusivamente en la lógica empresarial.

Si bien el diseño basado en dominios es compatible con la ingeniería basada en modelos y la arquitectura basada en modelos , ^[10] la intención detrás de ambos conceptos es diferente. La arquitectura basada en modelos se preocupa más por traducir un modelo en código para diferentes plataformas tecnológicas que por definir mejores modelos de dominio.

Sin embargo, las técnicas que proporciona la ingeniería basada en modelos (para modelar dominios, para crear lenguajes específicos de dominio para facilitar la comunicación entre expertos en el dominio y desarrolladores, etc.) facilitan el diseño basado en dominios 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 basada en modelos, el modelo de dominio se puede utilizar para generar el sistema de software real que lo gestionará. ^[11]

La segregación de responsabilidades entre consultas y comandos (CQRS) es un patrón arquitectónico para separar la lectura de datos (una "consulta") de la escritura de datos (un "comando"). CQRS deriva de Command and Query Separation (CQS), acuñado por Bertrand Meyer .

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

Si bien CQRS no requiere un diseño basado en dominios, hace explícita la distinción entre comandos y consultas con el concepto de raíz agregada. La idea es que una raíz agregada dada tiene un método que corresponde a un comando y un controlador de comandos invoca el método en la raíz agregada.

La raíz agregada es responsable de ejecutar la lógica de la operación y de generar una respuesta de error o simplemente de modificar su propio estado para que pueda escribirse en un almacén de datos. El controlador de comandos incorpora cuestiones de infraestructura relacionadas con el almacenamiento del estado de la raíz agregada y la creación de los contextos necesarios (por ejemplo, transacciones).

La técnica de modelado colaborativo basado en talleres puede utilizarse como precursor en el contexto del diseño impulsado por el dominio (DDD) para identificar y comprender los eventos del dominio. Este proceso de descubrimiento interactivo involucra a las partes interesadas, los expertos del dominio y los desarrolladores que trabajan juntos para visualizar el flujo de eventos del dominio, sus causas y sus efectos, fomentando una comprensión compartida del dominio. La técnica a menudo utiliza notas adhesivas codificadas por colores para representar diferentes elementos, como eventos del dominio, agregados y sistemas externos, lo que facilita una exploración clara y estructurada del dominio. La técnica de modelado colaborativo puede ayudar a descubrir subdominios, contextos delimitados y límites de agregados, que son construcciones clave en el DDD. Al centrarse en "lo que sucede" en el dominio, la técnica puede ayudar a descubrir procesos comerciales, dependencias e interacciones, proporcionando una base para implementar los principios del DDD y alinear el diseño del sistema con los objetivos comerciales. ^{[12] [13]}

El abastecimiento de eventos es un patrón arquitectónico en el que las entidades rastrean su estado interno no por medio de serialización directa o mapeo relacional de objetos, sino leyendo y confirmando eventos en un almacén de eventos .

Cuando se combina el abastecimiento de eventos con CQRS y el diseño impulsado por dominios, las raíces agregadas son responsables de validar y aplicar comandos (a menudo haciendo que sus métodos de instancia se invoquen desde un controlador de comandos) y luego publicar eventos. Esta es también la base sobre la que las raíces agregadas basan su lógica para tratar con 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 luego, a menudo, se publican en un agente de mensajes para aquellos interesados ​​(como la vista de una aplicación ).

El modelado de raíces agregadas para generar eventos puede aislar el estado interno aún más que cuando se proyectan datos leídos desde entidades, como en las arquitecturas estándar de paso de datos de n niveles. Un beneficio significativo 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 de manera integral su estado interno. Los eventos a menudo se conservan según 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 concurrencia optimista .

Un contexto delimitado, un concepto fundamental en el diseño impulsado por el dominio (DDD), define un área específica dentro de la cual un modelo de dominio es consistente y válido, lo que garantiza la claridad y la separación de preocupaciones. ^[15] En la arquitectura de microservicios , un contexto delimitado a menudo se asigna 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 solo microservicio, suele ser ideal ya que mantiene límites claros, reduce el acoplamiento y permite la implementación y el escalamiento independientes. Sin embargo, también pueden ser apropiadas otras asignaciones: 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 solo microservicio para simplificar o minimizar la sobrecarga operativa. La elección de la relación debe equilibrar los principios de DDD con los objetivos comerciales, las restricciones técnicas y los requisitos operativos del sistema. ^[16]

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

• Actifsource , un complemento para Eclipse que permite el desarrollo de software combinando DDD con ingeniería basada en 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 , un marco de trabajo web semántico de código abierto basado íntegramente en un modelo de datos. Las directivas de alto nivel permiten refinar el modelo de datos de forma iterativa, versión tras versión. Definir el modelo de datos es suficiente para obtener una aplicación web funcional. Se requiere más trabajo para definir cómo se muestran los datos cuando las vistas predeterminadas no son suficientes.
• OpenMDX , 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 , un estándar para mapear una API Restful a un modelo de objeto 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 de objetos Restful a partir de un modelo de dominio de manera automática, mediante reflexión.

• Arquitectura basada en células , una arquitectura de referencia descentralizada
• Malla de datos , una arquitectura de datos orientada al dominio
• Asalto a un evento
• Representación del conocimiento
• Ontología (ciencia de la información)
• Análisis semántico (representación del conocimiento)
• Redes semánticas
• Semántica
• Modelo C4
• Identificador fuertemente tipado
• Diseño integrado
• Ciencia de sistemas

• Diseño basado en dominios, definiciones y resúmenes de patrones (PDF) , Eric Evans, 2015
• Equipo DDD en GitHub: Canvas de contexto delimitado, Canvas agregado, Proceso de modelado y más repositorios
• Introducción al diseño basado en dominios, métodos y herramientas
• Implementación de la raíz agregada en lenguaje C#
• Context Mapper: un marco de modelado para el diseño estratégico basado en dominios (herramienta, tutoriales, ejemplos de modelado DDD)
• Actividad DDC estratégica en el repositorio de prácticas de diseño (DPR) y actividad DDC táctica en el repositorio de prácticas de diseño (DPR)