1. Domain Driven Design www.raona.com

2. DDD> Índice *) Índex ¿Y qué es esto con tantas D’s? Conceptos de DDD Ubiquitous Language PersistanceIgnorance El corazón del software Una arquitectura base

3. DDD> Índice *) Índex ¿Y qué es esto con tantas D’s? Conceptos de DDD Ubiquitous Language PersistanceIgnorance El corazón del software Una arquitectura base

5. Nace dentro del movimiento XP.

6. Programadores hablando con usuarios… (Parece mentira eh…)

7. Refactorización continua.

8. Se basa en:

9. Predominio del dominio sobre el resto de elementos de un sistema.

10. Es más importante un diseño consistente que las tecnologías empleadas.

11. Una propuesta contra el antipatrónAnemicDomainModel.

14. 1: Lenguaje Ubícuo (¿¿¿Claro no???)

15. 2: Lenguaje Omnipresente (Tooooooooooooooma)

16. Básicamente consiste en establecer un lenguaje que compartan todos los miembros de un equipo. Un lenguaje común.

17. Es la base sobre la que construimos un modelo.

18. Establecer este lenguaje es un proceso continuo durante el ciclo de vida del proyecto.

20. Como usuario quiero añadir fotos en los albumes.

21. Puedo tener albumesvaciosen ciertos momentos.

22. Como usuario quiero informar dónde se ha hecho la foto.

23. Como usuario quiero describir lo que aparece en la foto.

26. Como almacene los datos no debe condicionar el modelo.

27. Por extensión, como los muestre o los explote tampoco.Sistema de Gestión de Álbumes Fotográficos. Silverlight EF WPF NHibernate ASP.net ADO.net WinForms Sharepoint Gestión de autores Gestión de álbumes Gestión de fotografias

28. DDD> Índice *) Índex ¿Y qué es esto con tantas D’s? Conceptos de DDD Ubiquitous Language PersistanceIgnorance El corazón del software Una arquitectura base

30. El modelo es el corazón de nuestro software.

31. Las UI pueden mejorarse

32. Los repositorios de datos optimizarse o migrarse.

33. Pero la lógica de negocio debe ser consistente.

34. Promueve el uso de TDD.

35. Promueve el uso de Fakes y Mocks

36. Si está bien utilizado permite tener testeada la lógica de la aplicación.

40. Son solo clases POCO

43. Los podría representar como parte de una entidad pero forman una unidad por si mismaFotografia Fotografia DatosAuditoria + Id:int + Autor:Autor + Descripción:string + Lugar:Coordenadas + FechaCreacion:DateTime + UsuarioCreacion:String + FechaUltimaModificacion:DateTime + UsuarioUltimaModificacion:String + Id:int + Autor:Autor + Descripción:string + Lugar:Coordenadas + Auditoria: DatosAuditoria + FechaCreacion:DateTime + UsuarioCreacion:String + FechaUltimaModificacion:DateTime + UsuarioUltimaModificacion:String

46. A parte en mi sistema gestiono todas las direcciones de la provincia de Barcelona

47. Mi interés es el cliente.

48. No voy a hacer un sistema de rutas para enviar la factura.

51. Un cambio en el conjunto de datos afectaría al todo.

52. Permite modelar en pequeños subconjuntos.

53. Para acceder a los elementos de un agregado accedo a su principalUsuario Album Fotografia DatosAuditoria

54. DDD> Una arquitectura base

56. El uso de los elementos comentados añade complejidad a la construcción de los objetos.

57. Fomenta/Requiere el uso de Factorias.

60. Permite trabajar con objetos persistidos como si estuvieran en memoria.

61. En la practica solo definimos en una primera fase su Interfaz, su Contrato. Las operaciones que vamos a realizar contra él.

62. Esto nos permite utilizar fakes en la construcción de nuestro modelo ya que conocemos las operaciones.IAlbumRepository + AddAlbum(Albumalbum) + DeleteAlbum(Albumalbum) + UpdateAlbum(Albumalbum) + GetAlbum(intidAlbum)

64. Cuando añado un objeto a un DAO este se prepara para almacenarse, pero el DAO no se queda una instancia del mismo.

67. No todo va a ser añadir o modificar fotos. También quiero unir y separar álbumes.

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

69. La lógica es clara para el usuario y merece un método propio.

71. Los servicios del dominio contienen acciones del modelo.

72. Los servicios de aplicación acciones del sistema.

73. Son el punto de entrada al modelo. Aquí si que hay CRUD

74. Gestionan transacciones

75. Gestionan seguridad

76. Gestionan log

77. … hacen lo que es todo tecnología.

78. No son DDD, pero son esenciales para el funcionamiento.

80. DDD Quickly, Resumen del anterior y que está disponible en PDF desde InfoQ

81. Applying Domain-Driven Design and Patterns: With Examples in C# and .NET, Jimmy Nilson