DDD (Domain-Driven Design)

1.681 visualizaciones

Publicado el

Domain-Driven Design (DDD)

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
1.681
En SlideShare
0
De insertados
0
Número de insertados
306
Acciones
Compartido
0
Descargas
46
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

DDD (Domain-Driven Design)

  1. 1. Domain-Driven Design(DDD)twitter: @trukuxzo
  2. 2. Domain-Driven Design(DDD)Es una forma de diseñar el software centrándonosen lo que el cliente nos pide. El software quehacemos tiene como objetivo resolver unproblema de nuestro cliente.DDD es un estilo arquitectural. Se parece bastantea un estilo en N-Layer en tanto que los dos estilosseparan las responsabilidades de la aplicación,pero la forma de hacerlo es ligeramente distinta.
  3. 3. Capas vs Niveles (Layers vs. Tiers) Es la separación física enEs la forma de organizar el diferentes proyectoscódigo lógicamente y no físicamente
  4. 4. ConsideracionesNuestro lenguaje debe ser el mismo que el delusuario.No deberíamos usar otros términos.Tenemos que dejar de hablar de formas deimplementación (ej.: tablas) y pasar a hablaren términos menos técnicos, que estén máscerca del lenguaje del usuario y del negocio.
  5. 5. Ejemplos Escritos• “Si le damos al servicio de ruteo un origen, un destino, una fecha de llegada, puede buscar las paradas a hacer… Y guardarlas en la base de datos” (vago y técnico)• “El origen, destino y otros datos… se los damos al servicio de ruteo y nos devuelve un itinerario que tiene todo lo que necesitamos”(mejor, pero muchas palabras)• “Un servicio de ruteo encuentra un itinerario que satisface una especificación de ruta” (conciso)En este proceso de conversación con el usuario, se vandescubriendo sustantivos que representan conceptos deldominio.
  6. 6. Evans EscribeEn una aplicación de carga y envío demercadería, para simplemente listar y seleccionarel destino de la carga de una lista de ciudades,debe haber código que (1) dibuje un control en lapantalla, (2) consulte una base de datos paraobtener las posibles ciudades, (3) interprete elingreso de usuario y lo valide, (4) asocie laciudad seleccionada con la carga, y (5) confirmeel cambio en la base de datos. Todo este códigoes parte del mismo programa, pero sólo unapequeña parte está relacionado con el negocio deenvío de cargas.
  7. 7. Diagrama de Evans
  8. 8. User InterfaceLa más fácil de entender, esta capa es la responsablede mostrar información al usuario, y aceptar nuevosdatos. Puede ser implementada para web, escritoriográfico, o cualquier otra tecnología de presentación,presente o futura.Se pueden hacer las presentaciones en entornostales como: – Web: ASP.NET, ASP.NET MVC – WinForms – WPF – Silverlight
  9. 9. ApplicationDefine los trabajos que el software debe realizar ydirige los objetos del dominio para que trabajen encada problema.En general, es delgada, no contiene reglas denegocio o conocimiento, sino coordina tareas y delegael trabajo a colaboraciones de objetos del dominio.No mantiene estado que refleje la situación delnegocio, pero puede mantener estado sobre elprogreso de una tarea del usuario o programa
  10. 10. DomainEn esta capa reside el corazón del software, según Evans. Lasreglas y lógica de negocio residen en esta capa. El estado deentidades de negocio y su conducta es definida y usada aquí.La comunicación con otros sistemas, detalles de persistencia, sondelegados en la capa de Infraestructura mediante interfaces.Evans sugiere que se pueden ayudar con los patrones que él usaen esta capa, como: – Entities – Value Objects – Repositories – Services y – Factories.
  11. 11. InfraestructureEsta capa es la responsable de implementar el mecanismo depersistencia del modelo de dominio y de proporcionar laimplementación de todas las operaciones de comunicación.La capa de infraestructura implementa las interfaces de losrepositorios definidas en la capa de dominio para elmecanismo escogido (ficheros, base de datos, etc). y todasaquellas operaciones de comunicación con el mundo exteriorque necesite el dominio (Emailer,Logger, etc.)El mecanismo escogido para la persistencia debe sertransparente a la capa de dominio.
  12. 12. Diagrama Sugerida User Interface Views Controllers Services Application Application Web Services Services DomainDomain Domain Entities RepositoriesServices Infraestructure Repositories Utilities Implementation
  13. 13. Evans ProponeEl propone que el modelo de dominio resida en una capa, laCapa de Dominio. De esta forma, el modelo de dominio esprotegido de los detalles técnicos, como la implementaciónde la persistencia, y los detalles de presentación.Me gusta decir que el dominio es un organismo, que recibeestímulos, acciones desde el exterior, y reacciona a esoscomandos.El dominio debería ejecutarse sin conocimiento detalladodel resto de la aplicación, serialización entre capas físicas,detalles de presentación, y acceso a base de datos, debenestar claramente separados de la implementación deldominio.
  14. 14. Patrones Auxiliares - Entity• Tienen continuidad (viven a lo largo de la vida del sistema)• Tienen identidad• Pueden cambiar los valores, pero sigue siendo el mismo proveedor
  15. 15. Patrones Auxiliares – Value Objects• Los Value Objects se utilizan para representar conceptos importantes en nuestro dominio, pero su propósito es muy distinto al de las entidades• El objetivo de los Value Objects es describir un concepto importante para nuestro dominio• No son entidades por que no tienen una clave.
  16. 16. Patrones Auxiliares – Repository• Se necesitan recuperar objetos, en general Entities, una entity se puede alcanzar desde otra• En la capa de dominio definimos las interfaces que nuestro nivel de aplicación va a utilizar para para instanciar entidades de nuestro dominio pero no su implementación, esta se delega en la capa de infraestructura.• No se accede a la base de datos directamente
  17. 17. Patrones Auxiliares – Services• Frecuentemente en el dominio aparecen operaciones que no encajen bien dentro de ninguna entidad ya sea por que la operación tenga entidad por sí misma o por que la operación involucre a múltiples tipos de entidades.• También pueden ser operaciones que pueden cambiar según el caso (ej.: algoritmos de cálculo de descuento, etc.)• Los servicios de dominio solo deben ser utilizados para orquestar las operaciones entre entidades y no deben jamás tener estado interno.
  18. 18. Ejemplos.Net http://code.google.com/p/ndddsample/Java http://dddsample.sourceforge.net/
  19. 19. Fin

×