introducción a ddd

31
www.raona.com Domain Driven Design

Upload: sergiopolo

Post on 21-May-2015

2.656 views

Category:

Education


2 download

TRANSCRIPT

Page 1: Introducción a DDD

www.raona.com

DomainDrivenDesign

Page 2: Introducción a DDD

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

Page 3: Introducción a DDD

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

Page 4: Introducción a DDD

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?

Page 5: Introducción a DDD

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

Page 6: Introducción a DDD

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

Page 7: Introducción a DDD

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

Page 8: Introducción a DDD

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

Page 9: Introducción a DDD

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

Page 10: Introducción a DDD

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

Page 11: Introducción a DDD

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

Page 12: Introducción a DDD

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

Page 13: Introducción a DDD

DDD> Una arquitectura base

• Según lo expuesto por Eric Evans

Modelo teórico.

Page 14: Introducción a DDD

DDD> Una arquitectura base

• Según la última guía de Arquitectura de MS.

Modelo (algo) mas práctico.

Page 15: Introducción a DDD

DDD> Una arquitectura base

Page 16: Introducción a DDD

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.

Page 17: Introducción a DDD

DDD> Una arquitectura base

Page 18: Introducción a DDD

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

Page 19: Introducción a DDD

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.

Page 20: Introducción a DDD

DDD> Una arquitectura base

Page 21: Introducción a DDD

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

Page 22: Introducción a DDD

DDD> Una arquitectura base

Page 23: Introducción a DDD

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.

Page 24: Introducción a DDD

DDD> Una arquitectura base

Page 25: Introducción a DDD

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)

Page 26: Introducción a DDD

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.

Page 27: Introducción a DDD

DDD> Una arquitectura base

Page 28: Introducción a DDD

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.

Page 29: Introducción a DDD

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.

Page 30: Introducción a DDD

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

Page 31: Introducción a DDD

Applus >Moltes gràcies

Muchas gracias