Diseño Orientado al Dominio: Conceptos y Aplicaciones Prácticas

Apuntes:

Diseño orientado al dominio

Lo que hacemos es guiar nuestra aplicación y el diseño a través del uso del lenguaje común entre el negocio y el desarrollo. El obtener ese lenguaje del negocio y el poder hacer aplicaciones que estén concentradas en eso mucho más que lo que están concentradas en detalles técnicos. Va más allá de una sola aplicación, nos dice que busquemos modularizar nuestro sistema a través de los bounded context, que tratan de encontrar dónde el lenguaje cambia de sentido.

Pienso que 6 minutos se quedan cortos para explicar DDD. En este caso, hay todo un sumario de terminlogías y conceptos que no están ligados puramente a arquitectura.

Sería espectacular tener un curso aplicado únicamente a DDD.

Patrones: Diseño orientado al dominio

Se guía la aplicación y diseño a través del uso del lenguaje común entre el negocio y el desarrollo. Se trata de modelar el concepto y no tanto en especificar si es un servicio, factory o otro tipo de patron.

---

Los Contextos delimitados: (bounder context) Busca modularizar el sistema, estos contextos tratan de buscar en donde el lenguaje cambia de sentido.

---

Se concentra much en trabajar con el negocio y entender profundamente cual es el lenguaje que usan. Hay mucho valor en la semántica y mucho valor en la forma que se diseña y se conecta VS la forma en la que el negocio piensa.

------------ Diseño orientado al Dominio

• El diseño orientado al dominio genera módulos que se puedan desplegar por separado

• Guiar la aplicación através del uso del lenguaje común entre el negocio y el desarrollo

• Concentrar en ello las aplicaciones y no en el detalle técnico. Dice que se debe intentar modularizar la aplicación en Bounded Context.

• Tratan de encontrar donde el lenguaje cambia de sentido -> bounded context

• En el contexto de ventas el significado de producto es otro en comparación con el significado de inventarios.

• Aprovecha la separación semántica (propuesta por el negocio) para así separar nuestra aplicación

Dominio
Es toda la informacion del negocio, del problema que queremos resolver, es la corazon de nuestro DDD.

Ubiquitous Language
Es la comunicación efectiva entre los desarrolladores y los expertos del dominio. Un lenguaje común, que sea representado en el dominio, tanto como en los bounded contexts(subdominios), para asi lograr desarollar un software con los objetivos bien claros

Lo que se hace en un diseño orientado al dominio es llevar la aplicación mediante el uso de un lenguaje común entre el negocio (cliente) y el desarrollo del software (arquitecto/desarrollador). Esto va más allá de simplemente estar concentrado en detalles técnicos.

Su atención va completamente al problema relevante y ayuda a identificar una arquitectura para informar sobre las herramientas que se usarán en el desarrollo del software. Es una arquitectura con un lenguaje común, no solo técnico. Una arquitectura que todos puedan entender.

Las explicaciones muy buenas pero, no estaría mal que en los ejemplos fueran sobre algunas aplicaciones reales, y quizá un poco más a detalle de como se formó dicha aplicación con este patrón.

Saludos!!!

Arquitectura con N Capas orientada al dominio propuesta por microsoft en el libro: Guía de Arquitectura de N-Capas orientada al Dominio con .NET 4.0

### Patrón: Diseño Orientado al Dominio (Domain-Driven Design, DDD) El Diseño Orientado al Dominio es un enfoque integral para el desarrollo de software que busca alinearse estrechamente con los objetivos y la lógica del negocio. Este patrón enfatiza la colaboración entre expertos del dominio y desarrolladores para crear un modelo que refleje el entendimiento del dominio del problema, facilitando así la creación de soluciones más efectivas. #### Principios Clave 1. **Modelo del Dominio**: En el corazón de DDD se encuentra un modelo que describe los conceptos y relaciones del dominio. Este modelo se utiliza como una representación compartida entre los desarrolladores y expertos del dominio. 2. **Ubiquitous Language (Lenguaje Ubicuo)**: Se promueve el uso de un lenguaje común que todos los miembros del equipo (técnicos y no técnicos) comprenden y utilizan, lo que reduce malentendidos y mejora la comunicación. 3. **Contextos Limitados (Bounded Contexts)**: DDD sugiere dividir el dominio en contextos limitados, donde cada uno tiene su propio modelo y lógica. Esto ayuda a evitar confusiones y permite que diferentes partes del sistema evolucionen de manera independiente. 4. **Agregados**: Estructuras que agrupan entidades y objetos de valor relacionados, garantizando la consistencia de los datos dentro de sus límites. #### Ventajas del Diseño Orientado al Dominio * **Foco en el Dominio**: Permite a los desarrolladores centrarse en los aspectos más relevantes del negocio, mejorando así la efectividad de la solución. * **Colaboración Efectiva**: Fomenta la interacción continua entre expertos en el dominio y desarrolladores, lo que lleva a un mejor entendimiento del problema y a soluciones más alineadas con las necesidades del negocio. * **Modelos Claros**: Promueve la creación de modelos claros y bien definidos que pueden ser utilizados para guiar el desarrollo y facilitar la comunicación. * **Adaptabilidad**: Los sistemas pueden adaptarse más fácilmente a cambios en el negocio, ya que el modelo puede evolucionar conforme se adquiere una mejor comprensión del dominio. #### Desventajas del Diseño Orientado al Dominio * **Complejidad Inicial**: La implementación de DDD puede ser compleja y requerir tiempo, especialmente en proyectos pequeños donde el valor de DDD puede no ser evidente. * **Requiere Colaboración Activa**: La efectividad de DDD depende de la continua participación de expertos en el dominio, lo que puede ser un desafío en algunas organizaciones. * **Sobrecarga de Modelado**: Si no se gestiona adecuadamente, el proceso de modelado puede volverse demasiado complejo, lo que puede resultar en un aumento de la carga de trabajo y la dificultad para mantener el modelo. * **Curva de Aprendizaje**: Los equipos sin experiencia en DDD pueden enfrentar una curva de aprendizaje significativa, lo que puede retrasar el progreso en las fases iniciales del proyecto. #### Consideraciones Adicionales El Diseño Orientado al Dominio es más efectivo en proyectos donde el dominio es complejo y se requiere una comprensión profunda para resolver problemas. Es especialmente útil en entornos donde se anticipa una evolución frecuente del negocio. Al implementar DDD, es crucial mantener un enfoque iterativo y flexible, permitiendo que los modelos y la arquitectura evolucionen junto con el entendimiento del dominio.

### DDD (Domain-Driven Design) DDD se enfoca en diseñar sistemas complejos a partir del dominio del problema, asegurando que el software refleje con precisión las reglas y procesos del negocio. Sus componentes clave incluyen: * **Entidades** * **Objetos de Valor** * **Agregados** * **Repositorios** * **Servicios de Dominio** * **Eventos de Dominio** * **Contextos Delimitados (Bounded Contexts)** ### CQRS (Command Query Responsibility Segregation) CQRS es un patrón que complementa DDD al separar las responsabilidades de lectura (consulta) y escritura (comando). Este patrón puede ser útil para: * **Optimizar el rendimiento:** Separar las cargas de trabajo de lectura y escritura permite escalar cada una de manera independiente. * **Mejorar la claridad del código:** Divide las operaciones de escritura (que modifican el estado) y las de lectura (que consultan el estado). * **Facilitar la implementación de eventos:** Junto con event sourcing, CQRS puede mejorar la trazabilidad y la capacidad de auditar los cambios en el sistema. ### Relación entre DDD y CQRS * **DDD sin CQRS:** Puedes aplicar DDD sin necesidad de implementar CQRS. En este caso, tus servicios y repositorios manejarían tanto las operaciones de lectura como las de escritura. * **DDD con CQRS:** Puedes aplicar CQRS dentro del enfoque de DDD para optimizar y organizar mejor las operaciones de lectura y escritura.

En este ejemplo que pone el maestro, creo que aplica bastante bien, ya que inventario tiene una base de datos diferente a ventas.

Este patrón pone un fuerte enfoque en la lógica de negocio y cómo los dominios se relacionan con los modelos de la realidad del negocio. Vamos a suponer un proyecto de un sistema de gestión de inventarios para una empresa de e-commerce. ``` /inventory-management-system │ ├── /src │ ├── /domain # Capa de Dominio (lógica de negocio) │ │ ├── /models # Modelos del dominio (entidades y objetos de valor) │ │ │ ├── InventoryItem.ts # Entidad que representa un artículo de inventario │ │ │ ├── Category.ts # Entidad que representa una categoría de productos │ │ │ └── Supplier.ts # Entidad que representa un proveedor │ │ ├── /services # Servicios del dominio (reglas de negocio) │ │ │ └── InventoryService.ts # Lógica de negocio para la gestión del inventario │ │ ├── /repositories # Repositorios para acceder al almacenamiento de datos │ │ │ └── InventoryRepository.ts # Interfaz del repositorio de inventario │ │ ├── /exceptions # Excepciones de dominio (errores de negocio) │ │ │ └── InsufficientStockException.ts # Excepción cuando no hay stock suficiente │ │ └── /events # Eventos de dominio │ │ ├── ItemAddedEvent.ts # Evento cuando se añade un artículo al inventario │ │ └── StockLowEvent.ts # Evento cuando el stock de un artículo es bajo │ │ ├── /application # Capa de Aplicación (orquestación y casos de uso) │ │ ├── /use-cases # Casos de uso (lógica de aplicación) │ │ │ ├── AddInventoryItem.ts # Caso de uso para añadir un artículo al inventario │ │ │ ├── UpdateStock.ts # Caso de uso para actualizar el stock de un artículo │ │ │ └── GetInventoryReport.ts # Caso de uso para obtener un reporte de inventario │ │ ├── /dtos # Data Transfer Objects (DTOs) │ │ │ └── InventoryItemDTO.ts # DTO para transferir datos de un artículo de inventario │ │ └── /events # Eventos de la aplicación │ │ └── InventoryUpdatedEvent.ts # Evento de actualización de inventario │ │ ├── /infrastructure # Capa de Infraestructura (implementaciones técnicas) │ │ ├── /persistence # Implementación de los repositorios │ │ │ └── InventoryRepositoryImpl.ts # Implementación del repositorio de inventario │ │ ├── /messaging # Integración con sistemas de mensajería │ │ │ └── InventoryEventPublisher.ts # Publicador de eventos de inventario │ │ ├── /api # Adaptadores para la interfaz de usuario (APIs) │ │ │ ├── /rest # API REST para gestionar inventarios │ │ │ │ └── InventoryController.ts # Controlador REST para gestionar artículos de inventario │ │ │ └── /graphql # API GraphQL (si se usa) │ │ │ └── InventoryResolver.ts # Resolver para manejar consultas de inventario │ │ ├── /email # Integración con servicios de email │ │ │ └── StockAlertEmailSender.ts # Servicio para enviar alertas de stock bajo │ │ ├── /config # Configuraciones de infraestructura │ │ │ ├── /db # Configuración de la base de datos │ │ │ └── /message-queue # Configuración del sistema de mensajería │ │ └── /security # Implementación de seguridad (autenticación/autorización) │ │ └── SecurityConfig.ts # Configuración de seguridad para acceso a la API │ ├── /tests # Pruebas del proyecto │ ├── /domain # Pruebas unitarias para la capa de dominio │ ├── /application # Pruebas unitarias para los casos de uso │ ├── /infrastructure # Pruebas unitarias para infraestructura │ └── /integration # Pruebas de integración (interacción entre capas) │ ├── /docs # Documentación del proyecto │ ├── /domain-models.md # Descripción del modelo de dominio │ ├── /use-cases.md # Documentación de los casos de uso │ └── /api-spec.md # Especificaciones de la API (REST/GraphQL) │ ├── /scripts # Scripts auxiliares │ └── init-db.sh # Script para inicializar la base de datos │ ├── /logs # Carpeta para los logs del sistema │ └── inventory.log # Archivo de log del sistema de inventario │ ├── /build # Archivos generados en el proceso de build ├── /node\_modules # Dependencias del proyecto (si es un proyecto Node.js) ├── package.json # Archivo con las dependencias y scripts del proyecto ├── README.md # Documentación principal del proyecto └── .gitignore # Archivos y carpetas ignorados por Git ``` ### Explicación de la Estructura 1. **Domain (Dominio)**: * Esta es la capa más importante en DDD. Aquí se definen los **modelos de negocio** que representan el dominio, como entidades (`InventoryItem`, `Category`) y **objetos de valor**. * Los **servicios de dominio** contienen la lógica de negocio que no cabe naturalmente dentro de las entidades o objetos de valor. * Los **repositorios** son interfaces que definen cómo interactuar con los datos del dominio (acceso a la base de datos o fuentes externas), pero sin implementar directamente la lógica de persistencia. * Los **eventos de dominio** representan hechos importantes que han ocurrido en el sistema (por ejemplo, cuando se añade un nuevo artículo o el stock baja). 2. **Application (Aplicación)**: * Aquí se encuentran los **casos de uso** que orquestan las interacciones entre los diferentes elementos del dominio. Los casos de uso representan las acciones que puede realizar el sistema (añadir un artículo, actualizar stock, generar reportes, etc.). * Los **DTOs** (Data Transfer Objects) se utilizan para transferir datos entre capas sin exponer directamente los modelos del dominio. * Los **eventos de la aplicación** se emiten cuando ocurre algo relevante en los casos de uso, para que otras partes del sistema puedan reaccionar. 3. **Infrastructure (Infraestructura)**: * Esta capa contiene las implementaciones técnicas específicas para conectar el sistema con la **base de datos**, sistemas de **mensajería** (como RabbitMQ o Kafka), APIs externas, o servicios de notificación (por ejemplo, enviar emails). * Los **adaptadores** aquí son las implementaciones concretas de las interfaces definidas en el dominio (por ejemplo, `InventoryRepositoryImpl`), además de las interfaces que interactúan con el exterior, como la **API REST** o **GraphQL**. 4. **Tests**: * Contiene las **pruebas unitarias** e **integración**. Las pruebas se organizan por capas, y las pruebas de integración se encargan de verificar que las interacciones entre las distintas capas (dominio, aplicación, infraestructura) funcionen correctamente. 5. **Scripts e Infrastructure**: * Aquí están las configuraciones y scripts necesarios para la configuración del entorno, como inicializar la base de datos o configurar la seguridad de la aplicación. ### Principios de Domain-Driven Design * **Modelar el Dominio**: Los modelos del dominio reflejan conceptos de negocio que son importantes para la solución. * **Isolación del Dominio**: El dominio está separado de los detalles técnicos (como bases de datos o interfaces de usuario), lo que permite concentrarse en la lógica de negocio. * **Lógica de Negocio Clara**: Toda la lógica de negocio debe estar dentro del dominio. Otras capas (como la aplicación o infraestructura) solo deben orquestar o proveer soporte técnico. * **Eventos de Dominio**: Los eventos permiten que el sistema sea reactivo y extensible, ya que otros módulos pueden escuchar estos eventos y reaccionar a ellos sin afectar la lógica del dominio. Esta estructura refleja cómo la **lógica del negocio** es el centro del sistema y cómo las demás partes (infraestructura, APIs, etc.) se conectan al dominio a través de interfaces claramente definidas.

Resumen de IA Diseño Orientado al Dominio (DDD) El **Diseño Orientado al Dominio (DDD)** es una metodología de desarrollo de software centrada en la construcción de sistemas complejos mediante el uso de un modelo de dominio que está estrechamente alineado con los procesos y la terminología del negocio. El objetivo principal es hacer que el diseño del software refleje con precisión la lógica y los conceptos del negocio. ### Principios y Conceptos Clave 1. **Lenguaje Ubicuo (Ubiquitous Language)**: * Un lenguaje común compartido por todos los miembros del equipo, tanto técnicos como no técnicos. * Ayuda a reducir malentendidos y a asegurar que todos tengan una comprensión común del dominio. * Se utiliza en la documentación, código, y comunicación diaria. 2. **Modelo de Dominio**: * Una abstracción del dominio de negocio que se refleja en el diseño del software. * Captura los conceptos y las reglas del negocio. 3. **Bounded Contexts**: * Subdivisiones del modelo de dominio en las que ciertos términos y conceptos tienen significados específicos. * Cada bounded context tiene su propio modelo de dominio, claramente delimitado y separado de otros contexts. * Facilita la gestión de la complejidad al dividir el sistema en partes manejables y coherentes. 4. **Entidades y Valores**: * **Entidades**: Objetos que tienen identidad única y continuidad a lo largo del tiempo, independientemente de sus atributos. Ejemplo: Un cliente en un sistema de pedidos. * **Valores**: Objetos que no tienen identidad propia y se definen solo por sus atributos. Ejemplo: Una fecha o una cantidad de dinero. 5. **Agregados**: * Un conjunto de objetos que están relacionados entre sí y se tratan como una unidad de consistencia. * Un agregado tiene una raíz que garantiza la consistencia dentro de sus límites. 6. **Repositorios**: * Proveen métodos para recuperar y almacenar agregados. * Actúan como una colección de objetos que se puede buscar mediante criterios específicos. 7. **Servicios de Dominio**: * Operaciones o acciones que no encajan naturalmente en entidades o valores. * Representan lógica de negocio que no pertenece a un objeto específico. 8. **Fabricas**: * Usadas para la creación de objetos complejos o agregados. * Encapsulan la lógica de creación y aseguran la consistencia del objeto creado. 9. **Eventos de Dominio**: * Representan hechos significativos que ocurren en el dominio. * Son útiles para comunicar cambios de estado o acciones completadas entre diferentes partes del sistema. ### Estrategia de Implementación 1. **Colaboración y Comunicación**: * Trabaja estrechamente con expertos del dominio para entender los procesos y la terminología del negocio. * Utiliza el lenguaje ubicuo en todas las conversaciones, documentación y código. 2. **Modelado Iterativo**: * El modelo de dominio evoluciona a medida que se adquiere más conocimiento del negocio. * Realiza sesiones de modelado y revisiones frecuentes para refinar el modelo. 3. **Context Mapping**: * Identifica y define los bounded contexts. * Mapea las relaciones entre los diferentes contexts y define cómo se comunican entre sí. 4. **Implementación Técnica**: * Diseña entidades, valores, agregados, servicios, repositorios y eventos de acuerdo al modelo de dominio. * Utiliza frameworks y herramientas que faciliten la implementación de los principios de DDD (e.g., frameworks de inyección de dependencias, mapeadores ORM). ### Recursos Recomendados #### Libros 1. **"Domain-Driven Design: Tackling Complexity in the Heart of Software"** por Eric Evans * El libro fundamental sobre DDD que introduce y explica los conceptos en profundidad. 2. **"Implementing Domain-Driven Design"** por Vaughn Vernon * Ofrece una guía práctica para aplicar DDD con ejemplos detallados y estudios de casos. 3. **"Domain-Driven Design Distilled"** por Vaughn Vernon * Un resumen accesible y conciso de los conceptos clave de DDD.

Hola Gente, estoy trabajando para una empresa, alguien tiene un ejemplo de como aplicarlo al codigo?, en mi caso uso NET core y no se bien como aplicar esto a mi backend