Introducción a DDD
-
Upload
mariano-sanchez -
Category
Software
-
view
23 -
download
0
Transcript of Introducción a DDD
![Page 1: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/1.jpg)
Introducción a DDD
Mariano Sánchez
![Page 2: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/2.jpg)
¿Qué es Domain-Driven Design?
• Libro DDD, de Eric Evans.
• Premisas del Libro:
– El foco principal de un proyecto de software debe estar ubicado en el Dominio y la Lógica del Dominio.
– Tanto el Dominio como la Lógica del Dominio deben estar aislados de todo tema de implementación y tecnológico.
– Diseños de Dominios complejos deben basarse en un Modelo.
![Page 3: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/3.jpg)
Dominio• Dominio es el conjunto de factores que intervienen en la
solución del problema para el cual fue originado el software.
• Necesitamos entender el Dominio a nivel de detalle.
![Page 4: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/4.jpg)
Modelo de Dominio• El Modelo es una forma simplificada (selectivamente) y
estructurada del Dominio.
• El Modelo NO es un diagrama, el Modelo es una idea.
• El Modelo NO es Software (Está libre de temas tecnológicos).
• El Modelo y la Implementación DEBEN estar relacionados.
• El Modelo es conocimiento filtrado.
![Page 5: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/5.jpg)
Modelo de Dominio• Según Eric Evans, “El Modelo de Dominio es el Corazón del
Software”.
• Construir un Modelo de Dominio adecuado debe ser el foco principal del proyecto de software.
![Page 6: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/6.jpg)
Modelo de Dominio• El modelo debe capturar tanto los sustantivos como los
verbos importantes del dominio.
• Debe incluir: comportamiento, actividades del negocio y reglas del negocio.
• El Modelo debe ser conocido por todo el Equipo (Lenguaje Ubicuo).
• ¿Dónde esta el conocimiento?: Expertos del Dominio.
![Page 7: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/7.jpg)
Lenguaje Ubicuo• Los Expertos del Dominio tienen su lenguaje.
• Los Expertos en Software tienen otro lenguaje.
• Debe haber un lenguaje común para evitar traducir de uno a otro y reducir errores de comprensión.
• Todas las personas involucradas en el proyecto de software deben hablar este lenguaje.
• Es la base del Exito de DDD.
![Page 8: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/8.jpg)
Lenguaje Ubicuo
Espacio de la Solución Espacio del Problema
Términos Técnicos
Patrones de Diseño
Aspectos TécnicosConceptos del Dominio
Subdominios
El sistema a grandes razgos
Términos del Dominioque todos usan pero que no
aparecen en el diseño
Términos del NegocioDesconocidos por los
programadores
Expertos del DominioExpertos en Software
![Page 9: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/9.jpg)
Diagramas• Los Diagramas son buenos para entender el Modelo, pero no
pueden capturar toda la información.
• Los Diagramas no pueden capturar el comportamiento.
• El Modelo debe estar capturado en el Código.
![Page 10: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/10.jpg)
Implementando: Relación Modelo-Código• “Relacionando íntimamente el código con el modelo
subyacente, da al código significado y hace al modelo relevante”.
• El Modelo debe poder leerse desde el código.
• Implementación usando OOP y patrones DDD.
• Aislar las conceptos de Dominio de los conceptos Tecnológicos.
• Aislar el dominio del resto de la aplicación: Arquitectura en Capas.
![Page 11: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/11.jpg)
Implementando: Arquitectura en Capas
UI
APPLICATION
DOMAIN
INFRASTRUCTURE
![Page 12: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/12.jpg)
Capa Interfaz de Usuario (UI)• Es la responsable de interactuar con el usuario, interpretar sus
gestos y brindarle información.
• No contiene lógica del Dominio.
• Permite al usuario interactuar con los objetos del dominio.
• Por lo general es una capa delgada.
![Page 13: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/13.jpg)
Capa de Aplicación (Application)• Es la que contiene todo tema tecnológico accidental al
negocio.
• De existir interfaces con otros sistemas, es la encargada de realizar la comunicación para entregarle la información al dominio.
• Coordina el trabajo de la aplicación, no contiene lógica de negocio, pero maneja los objetos del dominio.
• Es la que conoce el comienzo y el final de una transacción.
• Por lo general es una capa delgada.
![Page 14: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/14.jpg)
Capa de Infraestructura (Infrastructure)
• Es la encargada de manejar la infraestructura del sistema, componentes externos, base de datos y frameworks.
• No contiene lógica de negocio, muchas veces es la encargada de persistir los objetos del dominio en un lugar físico (accidente tecnológico)
• Por lo general contiene una base de datos relacional y alguna herramienta ORM.
![Page 15: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/15.jpg)
Capa de Dominio (Domain)• Es el corazón del Software.
• “Los objetos del Dominio, libres de la responsabilidad de mostrarse, almacenarse y manejar las actividades de la aplicación. Enfocados en expresar el modelo. Esto permite capturar el conocimiento esencial del negocio y ponerlo a trabajar”.
• Esta capa es donde todos los conceptos, comportamientos y reglas especificadas por el Modelo son implementados.
• Las demás capas no deben contener “lógica del dominio”, tanto como sea posible.
![Page 16: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/16.jpg)
Ejemplo de Implementación
![Page 17: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/17.jpg)
Expresando el Modelo en Software• El Modelo debe poder leerse desde el código.
• Conceptos del Modelo:– Associations: Relaciones entre objetos y conceptos del
Modelo.– Entities: Objetos con identidad.– Value Objects: Objetos usados como atributos para
describir otros objetos (no tienen identidad).– Services: Acciones que modifican objetos y estados en el
dominio a pedido de un cliente.
![Page 18: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/18.jpg)
Associations• Por cada asociación en el modelo debe haber un mecanismo
en el software con las mismas propiedades.
• Tipos de asociaciones:– Uno-a-Uno– Uno-a-Muchos– Muchos-a-Muchos
• Eliminar todas las relaciones innecesarias.
• Eliminar bi-direccionalidades innecesarias.
![Page 19: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/19.jpg)
Entities• Algunos de los objetos no se definen principalmente por sus
atributos.
• Representan una identidad que se mantiene a lo largo de la aplicación.
• Comúnmente la identidad es un atributo del objeto mismo, una combinación de atributos, o un atributo creado especialmente para expresar esa identidad.
• Incluir atributos de identidad.
• Incluir solo comportamiento que ayude a mantener su identidad.
![Page 20: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/20.jpg)
Entities (Ejemplo)
![Page 21: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/21.jpg)
Value Objects • Algunos de los objetos no se definen principalmente por sus
atributos.
• Estos objetos sirven para describir otros objetos (Entities).
![Page 22: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/22.jpg)
Value Objects (Ejemplo)
![Page 23: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/23.jpg)
Services
• Son los verbos (acciones) del Modelo.
• Agregan comportamiento al Modelo.
• Manejan comportamiento no cohesivo a una Entity.
• Contienen Lógica y Reglas de Dominio.
![Page 24: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/24.jpg)
Services (Características))• La operación realizada por el Service refiere a un concepto de
domino que no es realizado naturalmente por un Entity o un Value Object.
• La operación realizada, modifica o usa otro objeto del dominio.
• La operación no guarda estado.
![Page 25: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/25.jpg)
Services (Ejemplo)
![Page 26: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/26.jpg)
Módulos• Los módulos son grupos de elementos de dominio.
• Proveen dos vistas del Modelo:» Vista de detalles del Módulo.» Vista de relación entre Módulos.
• Compilables por separado.
• Alta Cohesión y Bajo Acoplamiento.
![Page 27: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/27.jpg)
Mejando el Ciclo de Vida de los Objetos
• Cada objeto del dominio tiene un ciclo de vida.
• Retos del manejo del ciclo de vida:
– Mantener la Integridad de los objetos a través del ciclo de vida.
– Prevenir que el modelo se vea “inundado” por la complejidad del manejo del ciclo de vida.
• Solución: Patrones para el manejo del ciclo de vida.
![Page 28: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/28.jpg)
Patrones para el Manejo del Ciclo de Vida
• Aggregates: Proveen limites claros en el modelo, lo que permite reducir la complejidad del manejo.
• Factories: Usados para encapsular la complejidad de la creación o reconstrucción de objetos complejos (Aggregates).
• Repositories: Usados para encapsular la complejidad de tratar con objetos complejos persistentes.
28May 1, 2023
![Page 29: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/29.jpg)
Aggregates• Un Aggregate es un grupo de objetos relacionados, tratados
como uno solo.
• Cada Aggregate tiene un objeto Raíz y un límite claramente definido.
• Otros objetos solo pueden mantener referencias a la Raíz del Aggregate.
• Cuando se elimina un Aggregate, se debe eliminar todo su contenido (entre sus limites)
• Si es persistido, solo la Raíz debe ser obtenible por consultas. Objetos internos obtenidos a través de la raíz (uso de Lazy Load)
![Page 30: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/30.jpg)
Aggregates (Ejemplo)
![Page 31: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/31.jpg)
Factories• Los Factories son objetos esenciales en la capa de dominio
para encapsular la complejidad de crear y reconstruir objetos complejos.
• Un Factory es un objeto que encapsula la lógica, el conocimiento y los mecanismos necesarios para crear objetos complejos (Aggregates)
• A pesar de ser incluidos en la Capa de Domino, no pertenecen al modelo, son un recurso para disminuir la complejidad.
• Distintas implementaciones (GoF): Abstract Factory, Factory Method, Builder.
![Page 32: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/32.jpg)
Factories• El proceso de creación debe ser tan atómico como sea posible.
• Los Factories son especiales para crear Aggregates, cuando un Entity Raíz es creado, todos los objetos internos del Aggregate deben ser creados e inicializados sus valores.
• A veces los Factories no son necesarios y un simple constructor puede ser utilizado:
– La construcción no es compleja.– La creación de un objeto no involucra a otros, quizás todos
los atributos necesarios son pasados como parámetros al constructor.
– La implementación puede cambiar en tiempo de ejecución (patrón Strategy).
![Page 33: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/33.jpg)
Repositories• Los Respositories son objetos de dominio encargados de la
persistencia de los demás objetos.
• Encapsulan la lógica de persistencia y la conversación con la infraestrucutra.
• Si un objeto debe ser persistido, se envía el mismo al Repository (no importa el medio) y este se encarga de hablar con la infraestrucura para persistirlo.
![Page 34: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/34.jpg)
Repositories• Los Repositories no manejan transacciones (tema
tecnológico), estas son manejadas por la Capa de Aplicación.
• Es común que los Repositories usen Factories para reconstruir objetos complejos (Aggregates).
• Aíslan al dominio del medio de persistencia.
![Page 35: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/35.jpg)
Repositories• Los Repositories no manejan transacciones (tema
tecnológico), estas son manejadas por la Capa de Aplicación.
• Es común que los Repositories usen Factories para reconstruir objetos complejos (Aggregates).
• Aíslan al dominio del medio de persistencia.
![Page 36: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/36.jpg)
Ejemplo de Implementación
OrderFactory
OrderRepository
TotalCreditService+AddOrderLine(in orderLine)+IsOKAccordingToSize() : bool+IsOKAccordingToCreditLimit() : bool+Accept()
-TotalAmount-OrderDate-OrderNumber-OrderType-Status
Order
-NumberOfItems
OrderLine
1*
ReferencePerson
1 1
![Page 37: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/37.jpg)
Implementación Infraestrucura• Herramientas ORM.
• Una posible solución: Hibernate, Nhibernate, Entity Framework.
» Mapeo de objetos por metadata.» Implementación de Lazy Load.
![Page 38: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/38.jpg)
Preguntas?
![Page 39: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/39.jpg)
Bibliografía recomendada
39May 1, 2023
![Page 40: Introducción a DDD](https://reader035.fdocumento.com/reader035/viewer/2022070512/5899e7481a28ab96418b5803/html5/thumbnails/40.jpg)