Ya terminé de leer el libro de Eric Evans pero hay cosas que no me quedan muy claro con respecto a DDD.
Estas son algunas de las preguntas:
- Hacer Repositorios y Clases DAO no esta bien? Si hago repositorios no es necesario hacer clases DAO?
- Uso del patrón UnitOfWork: El patrón UnitOfWork es una lista de objetos modificados por transacciones. Pero es necesario hacerla al usar NHIbernate? Tengo entendido que NHIbernate implementa ese patrón.
- TDD = DDD: A no ser que DDD esta basado en el diseño del modelo y la implementacion de patrones específicos, el resto es todo igual?
1.- Creo que si sigues el patron de Repositorio, no es necesario DAO, o lo que yo entiendo por DAO.
2.- El objeto Session de nHibernate implementa ese patron.
3.- DDD de la forma mas simplista, es desarrollar tu modelo de entidades a partir de los requerimientos y despues desarrollar la aplicacion a partir de ahi. Nos olvidamos de crear primero el modelo de BD. TDD es una herramienta que te permite disenar tus entidades y conforme las disenas indicas las espectativas de estas.
TDD es muy distinto de DDD pero se complementan. DDD es una técnica de diseño de objetos, definiendo un modelo de dominio basado en el 'ubiquitous languaje'. TDD es una técnica de desarrollo que te permite, por medio de la definición de pruebas ir realizando pequeños incrementos codificando el modelo diseñado, al mismo tiempo que va contribuyendo a asegurar su calidad.
Tengo una imagen que muestra como colaboran estas técnicas de diseño y desarrollo en http://twitpic.com/ah31s.
Te recomiendo continuar tu lectura con el libro "Applying Domain-Driven Design and Patterns - With Examples in C# and .NET" es la aplicación del libro que leiste y de "Patterns of Enterprise Application Architecture" de Martin Fowler.
Tal como dice jgamba TDD es diferente a DDD, lo que coinciden que ambas son técnicas de diseño de software, pues en la primera se basa a modelar el sistema en base a los modelos de dominio, en cambio en TDD se basa en modelar el sistema en base a las especificaciones funcionales en donde primero se codifica que quiere que haga el sistema (mediante pruebas unitarias) y luego se construye el código que las satisface (o sea el código que implementa esas especificaciones), de esta forma tenemos muchas ventajas , como que se codifica solo lo que se requiere para la funcionalidad deseada hay mayor cobertura en el código, mayor control del código creado porque los casos de prueba sirven como documentación en formato ejecutable, facilidad para pruebas de regresión (ante cualquier cambio se corren todos los test para ver en donde afecta el cambio) entre otros. En el siguiente post hay más detalles sobre el tema, en donde intenté aclarar el panorama sobre TDD:
http://bit.ly/ha27E
Saludos a todos.
Tu Respuesta
YoProgramo.NET es una comunidad para unir y ayudar a los programadores hispanos.
Aquí los desarrolladores pueden encontrar repuesta a sus dudas y colaborar con los demás, compartiendo sus conocimientos y experiencia.