El documento aborda el diseño impulsado por el dominio (Domain Driven Design), enfatizando la importancia de entender el contexto del problema y usar un lenguaje común entre los involucrados. Se presentan conceptos clave como el 'lenguaje ubicuo', el 'contexto delimitado' y varios componentes del modelo, como entidades, objetos de valor y servicios. Además, menciona la separación de responsabilidades para comandos y consultas, y destaca la necesidad de integración continua en los contextos involucrados.

1. Domain Driven Design
Viernes 21 de Marzo
Innbit

2. Enfoque tradicional de diseño
De los casos de uso, se presume
que es suficiente para que ...
… los equipos de Desarrollo construyan
un sistema
! PERO NO ES SUFICIENTE !

3. Al diseñar un sistema, pensarlo en términos del Dominio
del problema a resolver
No diseñar en
términos técnicos o
problemas de TI

4. Por tanto el concepto de dominio ...
Ayuda a entender el contexto del
problema a ser resuelto por un sistema
de software
Y permite expresar el problema y la
solución en términos de un lenguaje
común a todos los que involucrados.

5. Model Driven Design

6. Ubiquitous Language

7. Bounded Context
Importante definir el contexto en el
cual el dominio aplica
El mapa de contexto es la vista global
de todos los contextos que participan
La consistencia de los contexto se debe
garantizar a través de integración continua

8. Como cualquier modelo, el meta modelo no es facil de
digerir ...
Manera de guardar información:
Entity, Value Object
Encapsular Complejidad del
modelo:
Aggregate
Procesamiento del
Modelo:
Service
Construcción del
Modelo:
Factory
Instrumentación del
modelo:
Event
Persistencia del modelo:
Repository

9. Entity
Tienen una identidad que los hace único
An object that is not defined
by its attributes, but rather
by a thread of continuity and
its identity.

10. Value Object An object that contains
attributes but has no
conceptual identity. They
should be treated as
immutable.

11. Aggregate A collection of objects that are bound together
by a root entity, otherwise known as an
aggregate root. The aggregate root guarantees
the consistency of changes being made within
the aggregate by forbidding external objects
from holding references to its members.
Encapsula complejidad

12. Domain Service
When an operation does not
conceptually belong to any object.
Following the natural contours of
the problem, you can implement
these operations in services
● Servicio no tiene estado
● Agnosticos a la infraestructura
de servicios subyacente

13. Factory
Methods for creating domain
objects should delegate to a
specialized Factory object such
that alternative implementations
may be easily interchanged.
La manera para construir y ensamblar los
bloques del dominio

14. Repository
Methods for retrieving domain
objects should delegate to a
specialized Repository object such
that alternative storage
implementations may be easily
interchanged.
● El concepto de repositorio es que el lenguaje del
dominio sea agnóstico al esquema de
almacenamiento y la implantación del repositorio
sea facilmente intercambiable
● Soportar esquemas de RDBMS, NoSQL,
InMemory Database, entre otros

15. Architecture

16. Application
● Una aplicación es cliente del modelo del dominio.
● La aplicación se especifica con los casos de uso
● Une la presentación, comunicación e infraestructura

17. El mapa
completo ...

19. Command & Query Responsibility Segregation - Diferente modelo
para consultar que para modificar -

20. Un ejemplo de uso de DDD
http://www.opentaps.org/docs/index.
php/Domain_Driven_Architecture

21. xDD

22. ! Gracias !