El diseño impulsado por dominio ( DDD ) es un importante enfoque de diseño de software , [1] que se centra en modelar software para que coincida con un dominio de acuerdo con las aportaciones de los expertos de ese dominio. [2]
En un diseño basado en dominios, 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éstamo, podría tener clases como "solicitud de préstamo", "clientes" y métodos como "aceptar oferta" y "retirar".
El diseño basado en dominios se basa en los siguientes objetivos:
Los críticos del diseño basado en dominios argumentan que los desarrolladores normalmente deben implementar una gran cantidad de aislamiento y encapsulación para mantener el modelo como una construcción pura y útil. Si bien el diseño basado en dominios proporciona beneficios como la capacidad de mantenimiento, Microsoft lo recomienda sólo para dominios complejos donde el modelo proporciona beneficios claros al formular una comprensión común del dominio. [3]
El término fue acuñado por Eric Evans en su libro del mismo título publicado en 2003. [4]
El diseño basado en dominios articula una serie de conceptos y prácticas de alto nivel. [4]
De primordial importancia 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 usarse para resolver problemas relacionados con ese dominio.
Estos aspectos del diseño basado en dominios tienen como objetivo fomentar un lenguaje común compartido por expertos, usuarios y desarrolladores del dominio: el lenguaje ubicuo . El lenguaje omnipresente 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 basado en dominios, la capa de dominio es una de las capas comunes en una arquitectura multicapa orientada a objetos .
El diseño basado en 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 en 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 visita, por ejemplo, sólo les importa 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 en el dominio. Los modelos pueden unirse mediante 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 agregada verifica la consistencia de los cambios en el agregado. Los conductores no tienen que controlar individualmente cada rueda de un coche, por ejemplo: simplemente conducen el coche. En este contexto, un automóvil es un agregado de varios otros objetos (el motor, los frenos, los faros, etc.).
En el diseño basado en dominios, la creación de un objeto suele estar separada del objeto mismo.
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 .
Aunque el diseño basado en dominios no está inherentemente ligado a los enfoques orientados a objetos , en la práctica explota las ventajas de tales técnicas. Estos incluyen entidades/raíces agregadas como receptores de comandos/invocaciones de métodos, la encapsulación del estado dentro de las principales raíces agregadas y, en un nivel arquitectónico superior, contextos acotados.
Como resultado, el diseño impulsado por dominio a menudo se asocia con objetos Java antiguos y objetos CLR antiguos , que son detalles de implementación técnica, específicos de Java y .NET Framework, respectivamente. Estos términos reflejan una visión cada vez mayor 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á a diseñar un mejor modelo de dominio. [5]
El diseño basado en dominios ha influido en otros enfoques del desarrollo de software.
El modelado de dominio específico , por ejemplo, es un diseño basado en dominio aplicado con lenguajes específicos de dominio . El diseño basado en dominios 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 soportar 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, permitiéndoles 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 , [6] la intención detrás de los dos 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 proporcionadas por la ingeniería basada en modelos (para modelar dominios, crear lenguajes específicos de dominio para facilitar la comunicación entre expertos y desarrolladores del dominio,...) facilitan el diseño basado en dominios en la práctica y ayudan a los profesionales a sacar más provecho de su trabajo. modelos. Gracias a las técnicas de generación de código y transformación de modelos de la ingeniería basada en modelos, el modelo de dominio se puede utilizar para generar el sistema de software real que lo gestionará. [7]
La segregación de responsabilidad de consulta de comandos (CQRS) es un patrón arquitectónico para separar la lectura de datos (una "consulta") de la escritura en datos (un "comando"). CQRS deriva de Command and Query Separation (CQS), acuñado por Bertrand Meyer .
Los comandos cambian de 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 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 determinada tenga un método que corresponda a un comando y un controlador de comandos invoque el método en la raíz agregada.
La raíz agregada es responsable de realizar la lógica de la operación y generar una respuesta de falla o simplemente mutar su propio estado que se puede escribir en un almacén de datos. El controlador de comandos incorpora preocupaciones de infraestructura relacionadas con guardar el estado de la raíz agregada y crear los contextos necesarios (por ejemplo, transacciones).
El abastecimiento de eventos es un patrón arquitectónico en el que las entidades rastrean su estado interno no mediante serialización directa o mapeo relacional de objetos, sino leyendo y enviando eventos a un almacén de eventos .
Cuando el origen de eventos se combina con CQRS y el diseño basado en dominios, las raíces agregadas son responsables de validar y aplicar comandos (a menudo invocando sus métodos de instancia desde un controlador de comandos) y luego publicar eventos. Ésta es también la base sobre la cual 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 intermediario de mensajes para aquellos interesados (como la vista de una aplicación ).
Modelar raíces agregadas para generar eventos puede aislar el estado interno incluso más que cuando se proyectan datos de lectura de 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, Contratos de Microsoft y CHESS [8] ) son más fáciles de aplicar, ya que la raíz agregada oculta completamente su estado interno. Los eventos a menudo persisten según la versión de la instancia raíz agregada, lo que produce un modelo de dominio que se sincroniza en sistemas distribuidos mediante concurrencia optimista .
Aunque el diseño basado en dominios no depende de ninguna herramienta o marco en particular, los ejemplos notables incluyen: