El diseño controlado por dominio ( DDD ) es el concepto de que 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 un software procesa solicitudes de préstamos, puede tener clases como LoanApplication y Customer, y métodos como AcceptOffer y Withdraw.
DDD conecta la implementación a un modelo en evolución. [1]
El diseño impulsado por dominios se basa en los siguientes objetivos:
- colocar el enfoque principal del proyecto en el dominio central y la lógica del dominio;
- basar diseños complejos en un modelo del dominio;
- iniciar una colaboración creativa entre técnicos y expertos en el dominio para refinar iterativamente un modelo conceptual que aborde problemas particulares del dominio.
El término fue acuñado por Eric Evans en su libro del mismo título. [2]
Conceptos
Los conceptos del modelo incluyen:
- Contexto
- El escenario en el que aparece una palabra o declaración que determina su significado;
- Dominio
- Esfera de conocimiento ( ontología ), influencia o actividad. El área temática a la que el usuario aplica un programa es el dominio del software;
- Modelo
- Un sistema de abstracciones que describe aspectos seleccionados de un dominio y puede usarse para resolver problemas relacionados con ese dominio;
- Lenguaje ubicuo
- Un lenguaje estructurado en torno al modelo de dominio y utilizado por todos los miembros del equipo para conectar todas las actividades del equipo con el software.
Bloques de construcción
En el libro Domain-Driven Design , [2] se articulan una serie de conceptos y prácticas de alto nivel, como el lenguaje ubicuo, lo que significa que el modelo de dominio debe formar un lenguaje común proporcionado por expertos en el dominio para describir los requisitos del sistema, que funciona igualmente bien para los usuarios comerciales o patrocinadores y para los desarrolladores de software. El libro se centra mucho en describir la capa de dominio como una de las capas comunes en un sistema orientado a objetos con una arquitectura de varias capas . En DDD, existen artefactos para expresar, crear y recuperar modelos de dominio:
- Entidad
- Un objeto que no se define por sus atributos, sino por un hilo de continuidad y su identidad .
- Ejemplo: la mayoría de las aerolíneas distinguen cada asiento de forma única en cada vuelo. Cada asiento es una entidad en este contexto. Sin embargo, Southwest Airlines, EasyJet y Ryanair no distinguen entre todos los asientos; todos los asientos son iguales. En este contexto, un asiento es en realidad un objeto de valor.
- Objeto de valor
- Un objeto de valor es un objeto que contiene atributos pero no tiene identidad conceptual. Deben ser tratados como inmutables .
- Ejemplo: cuando las personas intercambian tarjetas de presentación, generalmente no distinguen entre cada tarjeta única; solo les preocupa la información impresa en la tarjeta. En este contexto, las tarjetas de visita son objetos de valor.
- Agregar
- Un grupo de objetos que están unidos por una entidad raíz: la raíz agregada . 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 es responsable de verificar la consistencia de los cambios en el agregado.
- Ejemplo: cuando conduce un automóvil, no tiene que preocuparse por mover las ruedas hacia adelante, hacer que el motor se queme con chispas y combustible, etc .; simplemente está conduciendo el coche. En este contexto, el automóvil es un agregado de varios otros objetos y sirve como raíz agregada para todos los demás sistemas.
- Evento de dominio
- Un objeto de dominio que define un evento (algo que sucede). Un evento de dominio es un evento que preocupa a los expertos en el dominio.
- Servicio
- Cuando una operación no pertenece conceptualmente a ningún objeto. Siguiendo los contornos naturales del problema, puede implementar estas operaciones en los servicios. Consulte también Servicio (arquitectura de sistemas) .
- Repositorio
- Los métodos para recuperar objetos de dominio deben delegarse en un objeto Repository especializado de modo que las implementaciones de almacenamiento alternativas puedan intercambiarse fácilmente.
- Fábrica
- Los métodos para crear objetos de dominio deben delegarse en un objeto Factory especializado , de modo que las implementaciones alternativas puedan intercambiarse fácilmente.
Desventajas
Para ayudar a mantener el modelo como una construcción de lenguaje pura y útil, el equipo generalmente debe implementar una gran cantidad de aislamiento y encapsulación dentro del modelo de dominio. En consecuencia, un sistema basado en un diseño dirigido por dominios puede tener un costo relativamente alto. Si bien el diseño impulsado por dominios proporciona muchos beneficios técnicos, como la capacidad de mantenimiento, Microsoft recomienda que se aplique solo a dominios complejos donde el modelo y los procesos lingüísticos brindan beneficios claros en la comunicación de información compleja y en la formulación de un entendimiento común de el dominio. [3]
Relación con otras ideas
- Análisis y diseño orientado a objetos
- Aunque, en teoría, la idea general de DDD no necesita restringirse a enfoques orientados a objetos , en la práctica, DDD busca explotar las ventajas que las técnicas orientadas a objetos hacen posibles. Estos incluyen entidades / raíces agregadas como receptores de comandos / invocaciones de métodos y la encapsulación del estado dentro de las raíces agregadas más importantes y en un nivel arquitectónico superior, contextos delimitados.
- Ingeniería impulsada por modelos y arquitectura impulsada por modelos
- Si bien DDD es compatible con la ingeniería y la arquitectura impulsadas por modelos , respectivamente MDE / MDA [4], la intención de los dos conceptos es algo diferente. MDA se preocupa más por los medios de traducir un modelo en código para diferentes plataformas tecnológicas que por la práctica de definir mejores modelos de dominio. Las técnicas proporcionadas por MDE (para modelar dominios, crear DSL para facilitar la comunicación entre expertos y desarrolladores de dominios, ...) facilitan la aplicación de DDD en la práctica y ayudan a los practicantes de DDD 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 MDE, el modelo de dominio puede usarse no solo para representar el dominio sino también para generar el sistema de software real que se utilizará para administrarlo. Esta imagen muestra una posible representación de DDD y MDE combinados .
- Objetos Java antiguos sencillos y objetos CLR antiguos sencillos
- Plain Old Java Objects y Plain Old CLR Objects son conceptos de implementación técnica, específicos de Java y .NET Framework respectivamente. Sin embargo, la aparición de los términos POJO y POCO refleja una opinión cada vez mayor de que, dentro del contexto de cualquiera de esas plataformas técnicas, los objetos de dominio deben definirse puramente para implementar el comportamiento comercial del concepto de dominio correspondiente, en lugar de estar definidos por los requisitos. de un marco tecnológico más específico.
- El patrón de objetos desnudos
- El patrón de objetos desnudos se basa en la premisa de que si tiene un modelo de dominio suficientemente bueno, la interfaz de usuario puede ser simplemente un reflejo de este modelo de dominio; y que si requiere que la interfaz de usuario sea un reflejo directo del modelo de dominio, esto forzará el diseño de un mejor modelo de dominio. [5]
- Modelado específico de dominio
- El modelado específico de dominio (DSM) se aplica DDD mediante el uso de lenguajes específicos de dominio .
- Lenguaje específico del dominio
- DDD no requiere específicamente el uso de un lenguaje específico del dominio (DSL), aunque podría usarse para ayudar a definir un DSL y admitir métodos como el multimodelo específico del dominio .
- Programación Orientada a Aspectos
- La programación orientada a aspectos (AOP) facilita la eliminación de preocupaciones técnicas (como seguridad, gestión de transacciones, registro) de un modelo de dominio y, como tal, facilita el diseño e implementación de modelos de dominio que se centran exclusivamente en la lógica empresarial.
- Segregación de responsabilidad de consultas de comando
- La segregación de responsabilidad de consultas de comandos (CQRS) es un patrón arquitectónico para la separación de lecturas de escrituras, donde la primera es una consulta y la última es un comando. Los comandos mutan el estado y, por lo tanto, son aproximadamente equivalentes a la invocación de métodos en raíces / entidades agregadas. Las consultas leen el estado pero no lo mutan. CQRS es un patrón arquitectónico derivado del patrón de diseño llamado Separación de comandos y consultas (CQS) que fue acuñado por Bertrand Meyer . Si bien CQRS no requiere DDD, el diseño controlado por dominio hace que la distinción entre comandos y consultas sea explícita, en torno al 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 realizar la lógica de la operación y producir una cantidad de eventos o una respuesta de falla (excepción o enumeración / número de resultado de ejecución) O (si no se usa Event Sourcing (ES)) simplemente mutando su estado para una persiste la implementación, como un ORM, para escribir en un almacén de datos, mientras que el controlador de comandos es responsable de extraer las preocupaciones de infraestructura relacionadas con el almacenamiento del estado o los eventos de la raíz agregada y la creación de los contextos necesarios (por ejemplo, transacciones).
- Abastecimiento de eventos
- Event Sourcing (ES) es un patrón arquitectónico que garantiza que sus entidades (según la definición de Eric Evans ) no rastrean su estado interno mediante serialización directa o mapeo O / R, sino mediante la lectura y confirmación de eventos en un evento. tienda . Cuando ES se combina con CQRS y DDD, las raíces agregadas son responsables de validar y aplicar completamente los comandos (a menudo mediante la invocación de sus métodos de instancia desde un controlador de comandos) y luego publicar uno o un conjunto de eventos que también es la base en el 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 muchos eventos que se guardan transaccionalmente (confirmación única) en una tienda de eventos y luego, a menudo, se publican en un intermediario de mensajes para el beneficio de los interesados (a menudo, las vistas están interesadas; ellos luego se consultan mediante mensajes de consulta). Al modelar sus raíces agregadas para generar eventos, puede aislar el estado interno incluso más de lo que sería posible al proyectar datos de lectura de sus entidades, como se hace en las arquitecturas estándar de paso de datos de n niveles. Un beneficio significativo de esto es que las herramientas como los probadores de teoremas axiomáticos (por ejemplo, Microsoft Contracts y CHESS [6] ) son más fáciles de aplicar, ya que la raíz agregada oculta completamente su estado interno. Los eventos a menudo persisten en función de la versión de la instancia raíz agregada, lo que genera un modelo de dominio que se sincroniza en sistemas distribuidos en torno al concepto de simultaneidad optimista.
Herramientas notables
La práctica de DDD no depende del uso de ninguna herramienta o marco de software en particular. No obstante, existe un número creciente de aplicaciones que brindan soporte para los patrones específicos defendidos en el libro de Evans o el enfoque general de DDD. Las herramientas y marcos notables incluyen:
- Actifsource es un complemento para Eclipse que permite el desarrollo de software combinando DDD con ingeniería basada en modelos y generación de código .
- CubicWeb es un marco web semántico de código abierto totalmente impulsado por un modelo de datos. Las directivas de alto nivel permiten refinar el modelo de datos de forma iterativa, lanzamiento tras lanzamiento. Definir el modelo de datos es suficiente para obtener una aplicación web que funcione. Se requiere más trabajo para definir cómo se muestran los datos cuando las vistas predeterminadas no son suficientes.
- OpenMDX : código abierto, basado en Java, MDA Framework compatible con Java SE , Java EE y .NET . OpenMDX se diferencia de los marcos típicos de MDA en que "utilizan modelos para impulsar directamente el comportamiento en tiempo de ejecución de los sistemas operativos" .
- OpenXava : Genera una aplicación AJAX a partir de entidades JPA . Solo necesita escribir las clases de dominio para obtener una aplicación lista para usar.
- Restful Objects es un estándar para una API Restful en 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 Restful Objects a partir de un modelo de dominio automáticamente, utilizando la reflexión.
Ver también
- Asalto de eventos
- Representación del conocimiento
- Ontología (ciencia de la información)
- Análisis semántico (representación del conocimiento)
- Redes semánticas
- Semántica
Referencias
- ^ Diseño impulsado por dominio.
- ^ a b Evans, Eric (2004). Diseño basado en dominios: abordar la complejidad en el corazón del software . Addison-Wesley. ISBN 978-032-112521-7. Consultado el 12 de agosto de 2012 ..
- ^ Guía de arquitectura de aplicaciones de Microsoft, 2ª edición. Obtenido de http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle .
- ^ MDE puede considerarse como un superconjunto de MDA
- ^ Haywood, Dan (2009), Diseño basado en dominios utilizando objetos desnudos , Programadores pragmáticos.
- ^ una herramienta de búsqueda de errores de MS
enlaces externos
- Diseño impulsado por dominio, definiciones y resúmenes de patrones (PDF) , Eric Evans, 2015
- Implementación de raíz agregada en lenguaje C #
- Introducción al diseño , métodos y herramientas controlados por dominios