Diseño guiado por el dominio

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

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.

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

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.^[6]

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.^[6]

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

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:^[8] "un límite alrededor de todo el desorden", cuando no se pueden encontrar límites reales al analizar un sistema existente

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.^[9]

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,^[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 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á.^[11]

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.^[12][13]

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).

Modelar raíces de agregado para producir eventos puede aislar el estado interno incluso más que al proyectar datos de lectura desde entidades, como en las arquitecturas estándar de paso de datos en n-capas. 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 de agregado oculta completamente su estado interno. Los eventos suelen persistirse en función de la versión de la instancia de la raíz de agregado, lo que da lugar a un modelo de dominio que se sincroniza en sistemas distribuidos mediante control de concurrencia optimista.

Un contexto delimitado, un concepto fundamental en el Diseño Guiado por el Dominio (DDD), define un área específica dentro de la cual un modelo de dominio es coherente y válido, garantizando claridad y separación de responsabilidades.^[15] En la arquitectura de microservicios, un contexto delimitado suele mapearse a un microservicio, aunque 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 un despliegue y escalado 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 varios microservicios para abordar distintas necesidades de escalabilidad u operativas, mientras que una relación muchos a uno puede consolidar múltiples contextos delimitados en un solo microservicio por simplicidad o para minimizar la sobrecarga operativa. La elección de la relación debe equilibrar los principios de DDD con los objetivos de negocio del sistema, las restricciones técnicas y los requisitos operativos.^[16]

Aunque el diseño guiado por el dominio no depende de ninguna herramienta o framework en particular, algunos ejemplos destacados incluyen:

Actifsource, un complemento para Eclipse que permite el desarrollo de software combinando DDD con ingeniería dirigida por modelos y generación automática de código.

Context Mapper, un lenguaje específico del dominio y conjunto de herramientas para DDD estratégico y táctico.^[17]

CubicWeb, un framework semántico de código abierto completamente impulsado por 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 trabajo adicional para definir cómo se muestran los datos cuando las vistas predeterminadas no son suficientes.

OpenMDX, un framework MDA de código abierto basado en Java que soporta Java SE, Java EE y .NET. OpenMDX se diferencia de los frameworks MDA típicos en que "utiliza modelos para dirigir 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 objetos de dominio (donde los objetos de dominio pueden representar entidades, modelos de vista o servicios). Dos frameworks de código abierto (uno para Java y otro para .NET) pueden crear automáticamente una API Restful Objects a partir de un modelo de dominio utilizando reflexión.