Este documento introduce el Domain-Driven Design (DDD) y describe sus principales conceptos, incluyendo el modelo de dominio, lenguaje ubicuo, implementación mediante capas y patrones como agregados, fábricas y repositorios. El modelo de dominio captura los conceptos y reglas del negocio y debe reflejarse en el código para que el significado del dominio sea claro. DDD se enfoca en comprender el dominio y separar la lógica del negocio de los detalles tecnológicos.

1. Introducción a DDD
Mariano Sánchez

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

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

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

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

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

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

8. Lenguaje Ubicuo
Espacio de la Solución Espacio del Problema
Términos Técnicos
Patrones de Diseño
Aspectos Técnicos
Conceptos del Dominio
Subdominios
El sistema a grandes
razgos
Términos del Dominio
que todos usan pero que no
aparecen en el diseño
Términos del Negocio
Desconocidos por los
programadores
Expertos del DominioExpertos en Software

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

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

11. Implementando: Arquitectura en Capas
UI
APPLICATION
DOMAIN
INFRASTRUCTURE

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

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

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

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

16. Ejemplo de Implementación

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

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

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

20. Entities (Ejemplo)

21. Value Objects
• Algunos de los objetos no se definen principalmente por sus
atributos.
• Estos objetos sirven para describir otros objetos (Entities).

22. Value Objects (Ejemplo)

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

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

25. Services (Ejemplo)

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

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

28. 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.
2823 November 2016

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

30. Aggregates (Ejemplo)

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

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

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

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

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

36. Ejemplo de Implementación
OrderFactory
OrderRepository
TotalCreditService
+AddOrderLine(in orderLine)
+IsOKAccordingToSize() : bool
+IsOKAccordingToCreditLimit() : bool
+Accept()
-TotalAmount
-OrderDate
-OrderNumber
-OrderType
-Status
Order
-NumberOfItems
OrderLine
1
*
Reference
Person
1 1

37. Implementación Infraestrucura
• Herramientas ORM.
• Una posible solución: Hibernate, Nhibernate, Entity
Framework.
» Mapeo de objetos por metadata.
» Implementación de Lazy Load.

38. Preguntas?

39. Bibliografía recomendada
3923 November 2016