El diseño basado en dominio (DDD) es un enfoque para el desarrollo de software que se centra en comprender y modelar el dominio del problema dentro del cual opera un sistema de software. Enfatiza la importancia de colaborar estrechamente con expertos en el dominio para desarrollar una comprensión profunda de las complejidades del dominio. DDD proporciona un conjunto de principios, patrones y prácticas para ayudar a los desarrolladores a capturar y expresar de manera efectiva conceptos de dominio en sus diseños de software.

Linux cambia el nombre del directorio

Temas importantes para el diseño basado en dominios (DDD)

• ¿Qué es el diseño basado en dominios (DDD)?
• Importancia del conocimiento del dominio
• Diseño estratégico en diseño basado en dominios (DDD)
• Patrones de diseño táctico en diseño basado en dominios (DDD)
• Beneficios del diseño basado en dominios (DDD)
• Desafíos del diseño basado en dominios (DDD)
• Casos de uso del diseño basado en dominios (DDD)
• Ejemplo del mundo real de diseño basado en dominios (DDD)

¿Qué es el diseño basado en dominios (DDD)?

Dominio

Se refiere al área temática o espacio problemático para el cual se está construyendo el sistema de software. Abarca los conceptos, reglas y procesos del mundo real que el software pretende modelar o respaldar. Por ejemplo, en una aplicación bancaria, el dominio incluye conceptos como cuentas, transacciones, clientes y regulaciones relacionadas con las operaciones bancarias.

Impulsado

Impulsado implica que el diseño del sistema de software está guiado o influenciado por las características y requisitos del dominio. En otras palabras, las decisiones de diseño se basan en una comprensión profunda del dominio, en lugar de estar impulsadas únicamente por consideraciones técnicas o detalles de implementación.

Diseño

Diseño se refiere al proceso de creación de un plan o modelo para el sistema de software. Esto incluye decisiones sobre cómo se estructurará el sistema, cómo interactuarán los diferentes componentes y cómo el sistema cumplirá sus funciones. funcional y no funcional requisitos. En el contexto del diseño basado en dominio, la atención se centra en diseñar el software de una manera que refleje con precisión la estructura y el comportamiento del dominio.

El diseño basado en dominios es un concepto introducido por un programador. Eric Evans en 2004 en su libro Diseño basado en dominios: abordar la complejidad en el corazón del software

Importancia del conocimiento del dominio

Supongamos que hemos diseñado software utilizando la última tecnología e infraestructura y nuestra arquitectura de diseño de software es asombrosa, pero cuando lanzamos este software al mercado, en última instancia es el usuario final quien decide si nuestro sistema es excelente o no. Además, si el sistema no resuelve las necesidades del negocio, entonces no le sirve a nadie. No importa lo bonito que se vea o lo bien que sea la arquitectura de su infraestructura.

De acuerdo a Eric Evans Cuando desarrollamos software, nuestro enfoque no debe centrarse principalmente en la tecnología, sino principalmente en los negocios. Recordar,

No es trabajo del cliente saber lo que quiere – Steve Jobs

Diseño estratégico en diseño basado en dominios (DDD)

El diseño estratégico en diseño basado en dominios (DDD) se centra en definir la arquitectura y estructura generales de un sistema de software de una manera que se alinee con el dominio del problema. Aborda preocupaciones de alto nivel, como cómo organizar conceptos de dominio, cómo dividir el sistema en partes manejables y cómo establecer límites claros entre los diferentes componentes.

Veamos algunos conceptos clave dentro del Diseño Estratégico en Diseño Dirigido por Dominios (DDD)

1. Contextos acotados

• Un contexto acotado representa un área específica dentro del dominio del problema general donde un modelo o lenguaje particular se aplica de manera consistente.
• Diferentes partes de un sistema pueden tener diferentes significados para los mismos términos, y un contexto acotado define límites explícitos dentro de los cuales esos términos tienen significados específicos.
• Esto permite a los equipos desarrollar modelos que se adaptan a contextos específicos sin introducir confusión o inconsistencias.
• Los contextos acotados ayudan a gestionar la complejidad al dividir un dominio grande y complejo en partes más pequeñas y manejables.

2. Mapeo de contexto

• El mapeo de contexto es el proceso de definir las relaciones e interacciones entre diferentes contextos acotados.
• Implica identificar áreas de superposición o integración entre contextos y establecer canales de comunicación y acuerdos entre ellos.
• El mapeo de contexto ayuda a garantizar que las diferentes partes del sistema puedan colaborar de manera efectiva y al mismo tiempo mantener límites claros entre ellas.
• Existen varios patrones y técnicas para el mapeo de contexto, como asociación, kernel compartido y cliente-proveedor.

3. Patrones estratégicos

• Los patrones estratégicos son pautas o principios generales para organizar la arquitectura de un sistema de software de manera que se alinee con el dominio del problema.
• Estos patrones ayudan a abordar desafíos comunes en el diseño de sistemas complejos y proporcionan enfoques probados para estructurar el sistema de manera efectiva.
• Ejemplos de patrones estratégicos incluyen Agregados, Eventos de dominio y Capa anticorrupción.
• Estos patrones brindan soluciones a problemas recurrentes en el diseño basado en dominios y ayudan a garantizar que la arquitectura del sistema refleje con precisión los conceptos de dominio subyacentes.

4. Núcleo compartido

• El kernel compartido es un patrón estratégico que implica identificar áreas comunes entre diferentes contextos delimitados y establecer un subconjunto compartido del modelo de dominio que utilizan múltiples contextos.
• Este subconjunto compartido, o núcleo, ayuda a facilitar la colaboración y la integración entre contextos y al mismo tiempo permite que cada contexto mantenga su propio modelo distintivo.
• El kernel compartido debe utilizarse con prudencia, ya que introduce dependencias entre contextos y puede provocar un acoplamiento si no se gestiona con cuidado.

ordenamiento de burbuja

5. Capa Anticorrupción (ACL)

• La capa anticorrupción es otro patrón estratégico que ayuda a proteger un sistema de la influencia de sistemas externos o heredados que utilizan diferentes modelos o lenguajes.
• Una ACL actúa como una capa de traducción entre el sistema externo y el modelo de dominio central, transformando datos y mensajes según sea necesario para garantizar la compatibilidad.
• Esto permite que el modelo de dominio central permanezca puro y centrado en el dominio del problema, sin dejar de integrarse con sistemas externos según sea necesario.

6. Lenguaje ubicuo

El lenguaje ubicuo se refiere a un vocabulario o lenguaje compartido que se utiliza de manera consistente y universal entre todas las partes interesadas involucradas en el desarrollo de un sistema de software. Este lenguaje consta de términos, frases y conceptos que representan con precisión los conocimientos y conceptos del dominio.

Algunos de los principios clave del lenguaje ubicuo son:

• Entendimiento compartido : El objetivo principal de Ubiquitous Language es establecer una comprensión compartida del dominio del problema entre todos los miembros del equipo de desarrollo, incluidos desarrolladores, expertos en el dominio, analistas de negocios y partes interesadas. Al utilizar un lenguaje común, todos los involucrados pueden comunicarse de manera más efectiva y transmitir con precisión los conceptos y requisitos del dominio.
• Consistencia y claridad : El lenguaje ubicuo promueve la coherencia y la claridad en la comunicación mediante el uso de terminología precisa e inequívoca. Cada término o frase del idioma debe tener un significado claro y acordado,
• Alineación con conceptos de negocio : El lenguaje utilizado en DDD debe estar estrechamente alineado con la terminología y los conceptos utilizados en el ámbito empresarial. Debe reflejar la forma en que los expertos piensan y hablan sobre el dominio del problema, garantizando que el software represente con precisión conceptos y procesos del mundo real.
• Naturaleza evolutiva : El lenguaje ubicuo no es estático, sino que evoluciona con el tiempo a medida que el equipo adquiere una comprensión más profunda del dominio y los requisitos cambian. Debe adaptarse para reflejar nuevos conocimientos, descubrimientos o cambios en las prioridades comerciales, garantizando que el lenguaje siga siendo relevante y actualizado durante todo el proceso de desarrollo.

Patrones de diseño táctico en diseño basado en dominios (DDD)

En el diseño basado en dominios (DDD), los patrones de diseño táctico son estrategias o técnicas específicas que se utilizan para estructurar y organizar el modelo de dominio dentro de un sistema de software. Estos patrones ayudan a los desarrolladores a capturar de manera efectiva la complejidad del dominio, al mismo tiempo que promueven la mantenibilidad, la flexibilidad y la escalabilidad.

Veamos algunos de los patrones de diseño táctico clave en DDD:

1. Entidad

Una entidad es un objeto de dominio que tiene una identidad y un ciclo de vida distintos. Las entidades se caracterizan por sus identificadores únicos y su estado mutable. Encapsulan comportamiento y datos relacionados con un concepto específico dentro del dominio.

Por ejemplo, en una aplicación bancaria, unBankAccount>La entidad puede tener propiedades como número de cuenta, saldo y propietario, junto con métodos para depositar, retirar o transferir fondos.

2. Objeto de valor

Un objeto de valor es un objeto de dominio que representa un valor conceptualmente inmutable. A diferencia de las entidades, los objetos de valor no tienen una identidad distinta y normalmente se utilizan para representar atributos o propiedades de entidades. Los objetos de valor son comparables en términos de igualdad en función de sus propiedades, más que de su identidad.

Por ejemplo, unMoney>El objeto de valor puede representar una cantidad específica de moneda, encapsulando propiedades como el tipo de moneda y la cantidad.

3. Agregado

• Un agregado es un grupo de objetos de dominio que se tratan como una sola unidad con fines de coherencia de los datos e integridad transaccional.
• Los agregados constan de una o más entidades y objetos de valor, con una entidad designada como raíz agregada.
• La raíz del agregado sirve como punto de entrada para acceder y modificar el estado interno del agregado.
• Los agregados imponen límites de coherencia dentro del modelo de dominio, asegurando que los cambios en los objetos relacionados se realicen de forma atómica.

Por ejemplo, en un sistema de comercio electrónico, unOrder>El agregado podría consistir en entidades comoOrderItem>yCustomer>, con elOrder>entidad que actúa como raíz agregada.

4. Repositorio

• Un repositorio es un mecanismo para abstraer el acceso a datos y la lógica de persistencia del modelo de dominio.
• Los repositorios proporcionan una interfaz estandarizada para consultar y almacenar objetos de dominio, ocultando los detalles de cómo se recuperan o almacenan los datos. Los repositorios encapsulan la lógica para traducir entre objetos de dominio y mecanismos de almacenamiento de datos subyacentes, como bases de datos o servicios externos.
• Al desacoplar el modelo de dominio de las preocupaciones sobre el acceso a los datos, los repositorios permiten una mayor flexibilidad y mantenibilidad.

Por ejemplo, unCustomerRepository>podría proporcionar métodos para consultar y almacenarCustomer>entidades.

5. Fábrica

• Una fábrica es un patrón creacional se utiliza para encapsular la lógica para crear instancias de objetos de dominio complejos. Las fábricas abstraen el proceso de creación de instancias de objetos, lo que permite a los clientes crear objetos sin necesidad de conocer los detalles de su construcción.
• Las fábricas son particularmente útiles para crear objetos que requieren una lógica de inicialización compleja o involucran múltiples pasos.

Por ejemplo, unProductFactory>podría ser responsable de crear instancias deProduct>entidades con configuraciones predeterminadas.

6. Servicio

• Un servicio es un objeto de dominio que representa un comportamiento u operación que naturalmente no pertenece a ninguna entidad u objeto de valor específico.
• Los servicios encapsulan la lógica de dominio que opera en múltiples objetos u organiza interacciones entre objetos.
• Los servicios suelen ser apátridas y se centran en realizar tareas específicas o hacer cumplir reglas de dominio.

Por ejemplo, unOrderService>podría proporcionar métodos para procesar pedidos, aplicar descuentos y calcular los costos de envío.

Beneficios del diseño basado en dominios (DDD)

• Entendimiento compartido :
  • Fomenta la colaboración entre expertos en el dominio, desarrolladores y partes interesadas.
  • Al fomentar una comprensión compartida del dominio del problema a través del lenguaje omnipresente, los equipos pueden comunicarse de manera más efectiva y garantizar que el software refleje con precisión las necesidades y requisitos del negocio.
• Centrarse en el dominio principal :
  • Ayuda a los equipos a identificar y priorizar el dominio central de la aplicación: las áreas del sistema que brindan el mayor valor al negocio. Al centrar los esfuerzos de desarrollo en el dominio central, los equipos pueden ofrecer una funcionalidad que aborde directamente los objetivos comerciales y diferencie el software de la competencia.
• Resiliencia al cambio :
  • Enfatiza el diseño de sistemas de software que sean resistentes al cambio modelando el dominio de una manera que refleje las complejidades e incertidumbres inherentes del dominio del problema.
  • Al adoptar el cambio como una parte natural del desarrollo de software, los equipos pueden responder de manera más efectiva a las necesidades comerciales y las condiciones del mercado en evolución.
• Clara separación de preocupaciones :
  • DDD fomenta una clara separación de preocupaciones entre lógica de dominio, preocupaciones de infraestructura y preocupaciones de interfaz de usuario. Al aislar la lógica del dominio de los detalles técnicos y las preocupaciones de infraestructura, los equipos pueden mantener un modelo de dominio limpio y enfocado que es independiente de detalles de implementación específicos o opciones tecnológicas.
• Capacidad de prueba mejorada :
  • Promueve el uso de objetos de dominio con límites y comportamientos bien definidos, lo que facilita la redacción de pruebas mejores y enfocadas que verifiquen la corrección de la lógica del dominio.
  • Al diseñar sistemas de software teniendo en cuenta la capacidad de prueba, los equipos pueden garantizar que los cambios en el código base sean seguros y predecibles, lo que reduce el riesgo de introducir regresiones o efectos secundarios no deseados.
• Soporte para reglas comerciales complejas :
  • Proporciona patrones y técnicas para modelar e implementar reglas comerciales y flujos de trabajo complejos dentro del modelo de dominio.
  • Al representar las reglas comerciales explícitamente en el modelo de dominio, los equipos pueden garantizar que el software refleje con precisión las complejidades del dominio comercial y aplique restricciones y requisitos específicos del dominio.
• Alineación con los objetivos comerciales :
  • En última instancia, su objetivo es alinear los esfuerzos de desarrollo de software con las metas y objetivos estratégicos del negocio. Al centrarse en comprender y modelar el dominio del problema, los equipos pueden ofrecer soluciones de software que respalden directamente los objetivos comerciales, impulsen la innovación y creen valor para las partes interesadas y los usuarios finales.

Desafíos del diseño basado en dominios (DDD)

• Complejidad :
  • DDD puede introducir complejidad, especialmente en dominios grandes y complejos.
  • Modelar con precisión dominios comerciales complejos requiere una comprensión profunda del dominio y puede implicar lidiar con la ambigüedad y la incertidumbre. Gestionar esta complejidad de forma eficaz requiere una planificación, colaboración y experiencia cuidadosas.
• Adopción ubicua del lenguaje :
  • Establecer y mantener un lenguaje ubicuo (un vocabulario compartido que represente con precisión los conceptos del dominio) puede ser un desafío. Requiere colaboración entre desarrolladores y expertos en el dominio para identificar y acordar los términos y significados del dominio.
  • Lograr un consenso sobre el lenguaje omnipresente puede requerir superar las barreras de comunicación y conciliar diferencias en terminología y perspectivas.
• Alineación de contexto delimitada :
  • En dominios grandes y complejos, diferentes partes del dominio pueden tener modelos distintos y contextos acotados. Alinear estos contextos delimitados y garantizar la coherencia entre ellos puede resultar un desafío.
  • Requiere comunicación, colaboración y coordinación claras entre equipos que trabajan en diferentes partes del dominio para evitar inconsistencias y conflictos.
• Complejidad técnica :
  • La implementación eficaz de los principios y patrones de DDD puede requerir la adopción de nuevas tecnologías, marcos y enfoques arquitectónicos. La integración de DDD con sistemas existentes o bases de código heredadas puede ser compleja y puede requerir refactorizar o rediseñar el código existente para alinearlo con los principios de DDD.
  • Los desafíos técnicos como el rendimiento, la escalabilidad y la mantenibilidad deben abordarse cuidadosamente para garantizar el éxito de la adopción de DDD.
• Resistencia al cambio :
  • La introducción de DDD puede encontrar resistencia por parte de los miembros del equipo que están acostumbrados a los enfoques de desarrollo tradicionales o que perciben DDD como demasiado complejo o poco práctico.
  • Superar la resistencia al cambio requiere comunicación, educación y liderazgo efectivos para demostrar los beneficios de la DDD y abordar las preocupaciones y el escepticismo.
• Sobreingeniería :
  • Existe el riesgo de un exceso de ingeniería al aplicar DDD, donde los equipos se centran demasiado en modelar conceptos de dominio complejos e introducir abstracciones o complejidad innecesarias. Lograr el equilibrio adecuado entre simplicidad y expresividad es crucial para evitar complicar demasiado el diseño y la implementación.

Casos de uso del diseño basado en dominios (DDD)

• Finanzas y Banca :
  • En el sector financiero, DDD se puede utilizar para modelar instrumentos financieros, transacciones y requisitos regulatorios complejos. Al representar con precisión conceptos de dominio como cuentas, transacciones y carteras, DDD ayuda a garantizar la integridad y coherencia de los sistemas financieros. También permite una mejor gestión de riesgos, cumplimiento e informes.
• Comercio electrónico y venta minorista :
  • Las plataformas de comercio electrónico suelen tratar conceptos de dominio complejos, como catálogos de productos, gestión de inventario, precios y pedidos de clientes. DDD puede ayudar a modelar estos conceptos de manera efectiva, habilitando funciones como recomendaciones personalizadas, precios dinámicos y procesamiento de pedidos optimizado.
• Salud y ciencias biológicas :
  • En el sector sanitario, DDD se puede utilizar para modelar registros de pacientes, diagnósticos médicos, planes de tratamiento y flujos de trabajo sanitarios. Al representar con precisión conceptos de dominio como la demografía de los pacientes, los historiales médicos y los protocolos clínicos, DDD permite el desarrollo de sistemas sólidos de registros médicos electrónicos (EHR), plataformas de imágenes médicas y aplicaciones de telemedicina.
• Seguro :
  • Las compañías de seguros gestionan diversos productos, pólizas, reclamaciones y procesos de suscripción. DDD puede ayudar a modelar estos complejos conceptos de dominio, habilitando funciones como la gestión de pólizas, el procesamiento de reclamaciones, la evaluación de riesgos y el análisis actuarial.
• Bienes Raíces y Gestión de Propiedades :
  • La gestión de bienes raíces y propiedades implica el manejo de diversas propiedades, arrendamientos, inquilinos, solicitudes de mantenimiento y transacciones financieras. DDD puede ayudar a modelar estos conceptos de dominio de forma eficaz, habilitando funciones como listados de propiedades, gestión de arrendamientos, portales de inquilinos y seguimiento de activos.

Ejemplo del mundo real de diseño basado en dominios (DDD)

Planteamiento del problema

Digamos que estamos desarrollando una aplicación de transporte llamada RideX. El sistema permite a los usuarios solicitar viajes, a los conductores aceptar solicitudes de viajes y facilita la coordinación de viajes entre usuarios y conductores.

reemplazo de js

Lenguaje ubicuo

1. Usuario : Se refiere a personas que solicitan viajes a través de la plataforma RideX.
2. Conductor : Se refiere a personas que brindan viajes a los usuarios a través de la plataforma RideX.
3. Solicitud de viaje : representa la solicitud de viaje de un usuario y especifica detalles como el lugar de recogida, el destino y las preferencias de viaje.
4. Conducir : representa una instancia única de un viaje, incluidos detalles como lugares de recogida y devolución, tarifa y duración.
5. Estado del viaje : representa el estado actual de un viaje, como Solicitado, Aceptado, En progreso o Completado.

Contextos acotados

1. Contexto de gestión de viajes : Responsable de gestionar el ciclo de vida de los viajes, incluidas las solicitudes de viajes, las asignaciones de viajes a los conductores y las actualizaciones del estado de los viajes.
2. Contexto de gestión de usuarios : maneja la autenticación del usuario, el registro y funciones específicas del usuario, como el historial de viajes y los métodos de pago.
3. Contexto de gestión de conductores : gestiona la autenticación del conductor, el registro, el estado de disponibilidad y funciones específicas del conductor, como ganancias y calificaciones.

Entidades y objetos de valor

1. entidad de usuario : Representa un usuario registrado de la plataforma RideX, con propiedades como ID de usuario, correo electrónico, contraseña e información de pago.
2. Entidad conductora : Representa un conductor registrado en la plataforma RideX, con propiedades como ID del conductor, detalles del vehículo y estado del conductor.
3. Entidad de solicitud de viaje : representa la solicitud de viaje de un usuario, incluidas propiedades como ID de solicitud, lugar de recogida, destino y preferencias de viaje.
4. entidad de viaje : representa una única instancia de un viaje, incluidas propiedades como ID del viaje, lugares de recogida y devolución, tarifa y estado del viaje.
5. Objeto de valor de ubicación : Representa una ubicación geográfica, con propiedades como latitud y longitud.

Agregados

1. Montar agregado : consta de la entidad de viaje como raíz agregada, junto con entidades relacionadas, como las entidades de solicitud de viaje, usuario y conductor. Ride Aggregate encapsula la lógica para administrar el ciclo de vida de un viaje, incluido el manejo de solicitudes de viaje, la asignación de conductores y la actualización del estado del viaje.

Repositorio

1. Repositorio de viajes : proporciona métodos para consultar y almacenar entidades relacionadas con el viaje, como recuperar detalles del viaje, actualizar el estado del viaje y almacenar datos relacionados con el viaje en la base de datos.

Servicios

1. Servicio de asignación de viajes : Responsable de asignar conductores disponibles a las solicitudes de viaje en función de factores como la disponibilidad del conductor, la proximidad al lugar de recogida y las preferencias del usuario.
2. Servicio de pago : maneja el procesamiento de pagos para viajes completados, calcula tarifas, procesa pagos y actualiza la información de pago de usuarios y conductores.

Eventos de dominio

1. ViajeSolicitadoEvento : representa un evento que se activa cuando un usuario solicita un viaje y contiene información como los detalles de la solicitud de viaje y la identificación del usuario.
2. ViajeAceptadoEvento : Representa un evento que se activa cuando un conductor acepta una solicitud de viaje y contiene información como el ID del viaje, el ID del conductor y el lugar de recogida.

Escenario de ejemplo

1. Usuario solicitando un viaje : un usuario solicita un viaje proporcionando su lugar de recogida, destino y preferencias de viaje. RideX crea una nueva entidad de solicitud de viaje y activa un RideRequestedEvent.
2. Conductor aceptando un viaje : un conductor acepta una solicitud de viaje desde la plataforma RideX. RideX actualiza el estado del viaje a Aceptado, asigna al conductor al viaje y activa un RideAcceptedEvent.
3. Paseo en progreso : el usuario y el conductor coordinan el viaje, y el estado del viaje pasa de Aceptado a En curso una vez que el conductor llega al lugar de recogida.
4. Finalización del viaje : Después de llegar al destino, el estado del viaje se actualiza a Completado. RideX calcula la tarifa, procesa el pago y actualiza la información de pago del usuario y del conductor en consecuencia.