introducción a ddd

Introducción a DDD

Mariano Sánchez

¿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.

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.

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.

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.

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.

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.

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

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.

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.

Implementando: Arquitectura en Capas

UI

APPLICATION

DOMAIN

INFRASTRUCTURE

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.

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.

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.

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.

Ejemplo de Implementación

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.

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.

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.

Entities (Ejemplo)

Value Objects • Algunos de los objetos no se definen principalmente por sus

atributos.

• Estos objetos sirven para describir otros objetos (Entities).

Value Objects (Ejemplo)

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.

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.

Services (Ejemplo)

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.

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.

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

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)

Aggregates (Ejemplo)

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.

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).

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.

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.

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.

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

Implementación Infraestrucura• Herramientas ORM.

• Una posible solución: Hibernate, Nhibernate, Entity Framework.

» Mapeo de objetos por metadata.» Implementación de Lazy Load.

Preguntas?

Bibliografía recomendada

39May 1, 2023