introducción a ddd
TRANSCRIPT
www.raona.com
DomainDrivenDesign
DDD> Índice
*) Índex1. ¿Y qué es esto con tantas D’s?
2. Conceptos de DDD
1. Ubiquitous Language
2. Persistance Ignorance
3. El corazón del software
3. Una arquitectura base
DDD> Índice
*) Índex1. ¿Y qué es esto con tantas D’s?
2. Conceptos de DDD
1. Ubiquitous Language
2. Persistance Ignorance
3. El corazón del software
3. Una arquitectura base
DDD> ¿ Y que es esto con tantas D’s?
• Es una propuesta para desarrollar software desarrollada por Eric Evans en el libro Domain-Driven Design. Tackling Complexity in the Heart of Software
• Nace dentro del movimiento XP.• Programadores hablando con usuarios… (Parece mentira eh…)• Refactorización continua.
• Se basa en:• Predominio del dominio sobre el resto de elementos de un sistema.• Es más importante un diseño consistente que las tecnologías
empleadas.
• Una propuesta contra el antipatrón AnemicDomainModel.• POCO’s que hacían demasiado poco.
1. ¿Y que es esto con tantas D’s?
DDD> Índice
*) Índex1. ¿Y qué es esto con tantas D’s?
2. Conceptos de DDD
1. Ubiquitous Language
2. Persistance Ignorance
3. El corazón del software
3. Una arquitectura base
DDD> Conceptos de DDD
• Traducido al castellano de forma literal es:• 1: Lenguaje Ubícuo (¿¿¿Claro no???)• 2: Lenguaje Omnipresente (Tooooooooooooooma)
• Básicamente consiste en establecer un lenguaje que compartan todos los miembros de un equipo. Un lenguaje común.
• Es la base sobre la que construimos un modelo.
• Establecer este lenguaje es un proceso continuo durante el ciclo de vida del proyecto.
• Nos indica las entidades y las acciones que pueden formar parte del modelo.
Ubiquitous Language
DDD> Conceptos de DDD
• Como usuario quiero crear albumes de fotos.
• Como usuario quiero añadir fotos en los albumes.
• Puedo tener albumes vacios en ciertos momentos.
• Como usuario quiero informar dónde se ha hecho la foto.
• Como usuario quiero describir lo que aparece en la foto.
• Como usuario quiere decir quien ha hecho la foto
Ubiquitous Language
DDD> Índice
*) Índex1. ¿Y qué es esto con tantas D’s?
2. Conceptos de DDD
1. Ubiquitous Language
2. Persistance Ignorance
3. El corazón del software
3. Una arquitectura base
DDD> Conceptos de DDD
• Dentro de DDD no se graba, se persiste.
• Como almacene los datos no debe condicionar el modelo.
• Por extensión, como los muestre o los explote tampoco.
Persistance Ignorance
Sistema de Gestión de Álbumes
Fotográficos.
Gestión de autores
Gestión de álbumes
Gestión de fotografias
Silverlight
WPF
ASP.net
WinForms
EF
NHibernate
ADO.net
Sharepoint
DDD> Índice
*) Índex1. ¿Y qué es esto con tantas D’s?
2. Conceptos de DDD
1. Ubiquitous Language
2. Persistance Ignorance
3. El corazón del software
3. Una arquitectura base
DDD> Conceptos de DDD
• Con DDD construimos el corazón del software
• El modelo es el corazón de nuestro software. • Las UI pueden mejorarse• Los repositorios de datos optimizarse o migrarse.• Pero la lógica de negocio debe ser consistente.
• Promueve el uso de TDD.
• Promueve el uso de Fakes y Mocks
• Si está bien utilizado permite tener testeada la lógica de la aplicación.
• Al ser independiente este test se puede realizar en segundos.
El corazón del software
DDD> Índice
*) Índex1. ¿Y qué es esto con tantas D’s?
2. Conceptos de DDD
1. Ubiquitous Language
2. Persistance Ignorance
3. El corazón del software
3. Una arquitectura base
DDD> Una arquitectura base
• Según lo expuesto por Eric Evans
Modelo teórico.
DDD> Una arquitectura base
• Según la última guía de Arquitectura de MS.
Modelo (algo) mas práctico.
DDD> Una arquitectura base
DDD> Entidades
• Una entidad tiene identidad propia.
• Son solo clases POCO
• Pero no POCO puras
Album+ Id:int+ Codigo:string+ Descripcion:string- Fotografias:IEnumerable<Fotografia>+ AddFotografia(Fotografia fotografia)
•La puedo representar con un Id.
DDD> Una arquitectura base
DDD> Objetos-Valor
• Representan un valor.
• Los podría representar como parte de una entidad pero forman una unidad por si misma
Fotografia
+ Id:int+ Autor:Autor+ Descripción:string+ Lugar:Coordenadas+ FechaCreacion:DateTime+ UsuarioCreacion:String+ FechaUltimaModificacion:DateTime+ UsuarioUltimaModificacion:String
Fotografia+ Id:int+ Autor:Autor+ Descripción:string+ Lugar:Coordenadas+ Auditoria: DatosAuditoria
DatosAuditoria
+ FechaCreacion:DateTime+ UsuarioCreacion:String+ FechaUltimaModificacion:DateTime+ UsuarioUltimaModificacion:String
DDD> Objetos-Valor
• Un objeto-valor es una herramienta
• El mismo concepto en un modelo puede ser un objeto-valor y en otro una entidad
Sistema Logístico Sistema Contable
C/ Aribau, 44.Sant Cugat del Vallés
• Un cambio en la dirección condiciona mi sistema de calculo de rutas.
• A parte en mi sistema gestiono todas las direcciones de la provincia de Barcelona
Cliente 1423C/ Aribau, 44.Sant Cugat del VallésDir. Fact.
• Mi interés es el cliente.
• No voy a hacer un sistema de rutas para enviar la factura.
• Almacenar de forma independiente las direcciones no me aporta nada.
Cliente 1423
Dir. Ent.
DDD> Una arquitectura base
DDD> Agregados
• Representan el límite lógico de un conjunto de datos.
• Un cambio en el conjunto de datos afectaría al todo.
• Permite modelar en pequeños subconjuntos.
• Para acceder a los elementos de un agregado accedo a su principal
Album
FotografiaDatosAuditori
a
Usuario
DDD> Una arquitectura base
DDD> Factorias
• Son los elementos encargados de crear los objetos del sistema.
• El uso de los elementos comentados añade complejidad a la construcción de los objetos.
• Fomenta/Requiere el uso de Factorias.
• En sistemas sin ORM’s tambien se encargan de la construcción de los objetos persistidos.
DDD> Una arquitectura base
DDD> Repositorios
• Patrón de Acceso a datos
• Permite trabajar con objetos persistidos como si estuvieran en memoria.
• En la practica solo definimos en una primera fase su Interfaz, su Contrato. Las operaciones que vamos a realizar contra él.
• Esto nos permite utilizar fakes en la construcción de nuestro modelo ya que conocemos las operaciones.
IAlbumRepository
+ AddAlbum(Album album)+ DeleteAlbum(Album album)+ UpdateAlbum(Album album)+ GetAlbum(int idAlbum)
DDD> Repositorios
• Un repositorio != DAO
• Cuando añado un objeto a un DAO este se prepara para almacenarse, pero el DAO no se queda una instancia del mismo.
• En un repositorio la instancia del objeto se mantiene hasta que los cambios se persisten.
DDD> Una arquitectura base
DDD> Servicios del dominio
• Los servicios del dominio contienen acciones dentro del modelo que no se pueden representar en una entidad.
• No todo va a ser añadir o modificar fotos. También quiero unir y separar álbumes.
• Según los usuarios unir álbumes consiste en la creación de un único álbum que contenga las fotografías de todos los demás. Y todos los demás álbumes desaparecen.
• La lógica es clara para el usuario y merece un método propio.
• No requiero servicios del dominio para las operaciones CRUD simples. Estas están implementadas en los repositorios.
DDD> Servicios del dominio
• Servicio de Dominio != Servicio de Aplicación
• Los servicios del dominio contienen acciones del modelo.
• Los servicios de aplicación acciones del sistema.• Son el punto de entrada al modelo. Aquí si que hay CRUD• Gestionan transacciones• Gestionan seguridad• Gestionan log• … hacen lo que es todo tecnología.
• No son DDD, pero son esenciales para el funcionamiento.
• Si DDD se implementa en un servidor .NET serían los servicios WCF.
DDD> Bibliografia
• Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans
• DDD Quickly, Resumen del anterior y que está disponible en PDF desde InfoQ
• Applying Domain-Driven Design and Patterns: With Examples in C# and .NET, Jimmy Nilson
• Guia de Arquitectura N-Capas orientada al Dominio con .NET 4.0, VVAA
Applus >Moltes gràcies
Muchas gracias