SlideShare una empresa de Scribd logo

DDD (Domain-Driven Design)

•Descargar como PPTX, PDF•
•
Senior Dev
Senior Dev

Este documento describe el diseño orientado a dominio (DDD), un estilo arquitectónico que separa la aplicación en capas lógicas centradas en el dominio del negocio. Explica que la capa del dominio contiene la lógica y reglas del negocio, mientras que las capas de interfaz de usuario, aplicación e infraestructura se encargan de la presentación, coordinación y almacenamiento respectivamente. También discute patrones como entidades, objetos de valor, repositorios y servicios que ayudan a modelar el dominio

1 de 19
Domain-Driven Design(DDD) twitter: @trukuxzo
Domain-Driven Design(DDD) Es una forma de diseñar el software centrándonos en lo que el cliente nos pide. El software que hacemos tiene como objetivo resolver un problema de nuestro cliente. DDD es un estilo arquitectural. Se parece bastante a un estilo en N-Layer en tanto que los dos estilos separan las responsabilidades de la aplicación, pero la forma de hacerlo es ligeramente distinta.
Capas vs Niveles (Layers vs. Tiers) Es la separación física en Es la forma de organizar el diferentes proyectos código lógicamente y no físicamente
Consideraciones Nuestro lenguaje debe ser el mismo que el del usuario. No deberíamos usar otros términos. Tenemos que dejar de hablar de formas de implementación (ej.: tablas) y pasar a hablar en términos menos técnicos, que estén más cerca del lenguaje del usuario y del negocio.
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 van descubriendo sustantivos que representan conceptos del dominio.
Evans Escribe En una aplicación de carga y envío de mercadería, para simplemente listar y seleccionar el destino de la carga de una lista de ciudades, debe haber código que (1) dibuje un control en la pantalla, (2) consulte una base de datos para obtener las posibles ciudades, (3) interprete el ingreso de usuario y lo valide, (4) asocie la ciudad seleccionada con la carga, y (5) confirme el cambio en la base de datos. Todo este código es parte del mismo programa, pero sólo una pequeña parte está relacionado con el negocio de envío de cargas.
Diagrama de Evans
User Interface La más fácil de entender, esta capa es la responsable de mostrar información al usuario, y aceptar nuevos datos. Puede ser implementada para web, escritorio gráfico, o cualquier otra tecnología de presentación, presente o futura. Se pueden hacer las presentaciones en entornos tales como: – Web: ASP.NET, ASP.NET MVC – WinForms – WPF – Silverlight
Application Define los trabajos que el software debe realizar y dirige los objetos del dominio para que trabajen en cada problema. En general, es delgada, no contiene reglas de negocio o conocimiento, sino coordina tareas y delega el trabajo a colaboraciones de objetos del dominio. No mantiene estado que refleje la situación del negocio, pero puede mantener estado sobre el progreso de una tarea del usuario o programa
Domain En esta capa reside el corazón del software, según Evans. Las reglas y lógica de negocio residen en esta capa. El estado de entidades de negocio y su conducta es definida y usada aquí. La comunicación con otros sistemas, detalles de persistencia, son delegados en la capa de Infraestructura mediante interfaces. Evans sugiere que se pueden ayudar con los patrones que él usa en esta capa, como: – Entities – Value Objects – Repositories – Services y – Factories.
Infraestructure Esta capa es la responsable de implementar el mecanismo de persistencia del modelo de dominio y de proporcionar la implementación de todas las operaciones de comunicación. La capa de infraestructura implementa las interfaces de los repositorios definidas en la capa de dominio para el mecanismo escogido (ficheros, base de datos, etc). y todas aquellas operaciones de comunicación con el mundo exterior que necesite el dominio (Emailer,Logger, etc.) El mecanismo escogido para la persistencia debe ser transparente a la capa de dominio.
Diagrama Sugerida User Interface Views Controllers Services Application Application Web Services Services Domain Domain Domain Entities Repositories Services Infraestructure Repositories Utilities Implementation
Evans Propone El propone que el modelo de dominio resida en una capa, la Capa de Dominio. De esta forma, el modelo de dominio es protegido de los detalles técnicos, como la implementación de la persistencia, y los detalles de presentación. Me gusta decir que el dominio es un organismo, que recibe estímulos, acciones desde el exterior, y reacciona a esos comandos. El dominio debería ejecutarse sin conocimiento detallado del resto de la aplicación, serialización entre capas físicas, detalles de presentación, y acceso a base de datos, deben estar claramente separados de la implementación del dominio.
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
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.
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
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.
Ejemplos .Net http://code.google.com/p/ndddsample/ Java http://dddsample.sourceforge.net/
Fin

Más contenido relacionado

DDD (Domain-Driven Design)

  • 2. Domain-Driven Design(DDD) Es una forma de diseñar el software centrándonos en lo que el cliente nos pide. El software que hacemos tiene como objetivo resolver un problema de nuestro cliente. DDD es un estilo arquitectural. Se parece bastante a un estilo en N-Layer en tanto que los dos estilos separan las responsabilidades de la aplicación, pero la forma de hacerlo es ligeramente distinta.
  • 3. Capas vs Niveles (Layers vs. Tiers) Es la separación física en Es la forma de organizar el diferentes proyectos código lógicamente y no físicamente
  • 4. Consideraciones Nuestro lenguaje debe ser el mismo que el del usuario. No deberíamos usar otros términos. Tenemos que dejar de hablar de formas de implementación (ej.: tablas) y pasar a hablar en términos menos técnicos, que estén más cerca del lenguaje del usuario y del negocio.
  • 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 van descubriendo sustantivos que representan conceptos del dominio.
  • 6. Evans Escribe En una aplicación de carga y envío de mercadería, para simplemente listar y seleccionar el destino de la carga de una lista de ciudades, debe haber código que (1) dibuje un control en la pantalla, (2) consulte una base de datos para obtener las posibles ciudades, (3) interprete el ingreso de usuario y lo valide, (4) asocie la ciudad seleccionada con la carga, y (5) confirme el cambio en la base de datos. Todo este código es parte del mismo programa, pero sólo una pequeña parte está relacionado con el negocio de envío de cargas.
  • 8. User Interface La más fácil de entender, esta capa es la responsable de mostrar información al usuario, y aceptar nuevos datos. Puede ser implementada para web, escritorio gráfico, o cualquier otra tecnología de presentación, presente o futura. Se pueden hacer las presentaciones en entornos tales como: – Web: ASP.NET, ASP.NET MVC – WinForms – WPF – Silverlight
  • 9. Application Define los trabajos que el software debe realizar y dirige los objetos del dominio para que trabajen en cada problema. En general, es delgada, no contiene reglas de negocio o conocimiento, sino coordina tareas y delega el trabajo a colaboraciones de objetos del dominio. No mantiene estado que refleje la situación del negocio, pero puede mantener estado sobre el progreso de una tarea del usuario o programa
  • 10. Domain En esta capa reside el corazón del software, según Evans. Las reglas y lógica de negocio residen en esta capa. El estado de entidades de negocio y su conducta es definida y usada aquí. La comunicación con otros sistemas, detalles de persistencia, son delegados en la capa de Infraestructura mediante interfaces. Evans sugiere que se pueden ayudar con los patrones que él usa en esta capa, como: – Entities – Value Objects – Repositories – Services y – Factories.
  • 11. Infraestructure Esta capa es la responsable de implementar el mecanismo de persistencia del modelo de dominio y de proporcionar la implementación de todas las operaciones de comunicación. La capa de infraestructura implementa las interfaces de los repositorios definidas en la capa de dominio para el mecanismo escogido (ficheros, base de datos, etc). y todas aquellas operaciones de comunicación con el mundo exterior que necesite el dominio (Emailer,Logger, etc.) El mecanismo escogido para la persistencia debe ser transparente a la capa de dominio.
  • 12. Diagrama Sugerida User Interface Views Controllers Services Application Application Web Services Services Domain Domain Domain Entities Repositories Services Infraestructure Repositories Utilities Implementation
  • 13. Evans Propone El propone que el modelo de dominio resida en una capa, la Capa de Dominio. De esta forma, el modelo de dominio es protegido de los detalles técnicos, como la implementación de la persistencia, y los detalles de presentación. Me gusta decir que el dominio es un organismo, que recibe estímulos, acciones desde el exterior, y reacciona a esos comandos. El dominio debería ejecutarse sin conocimiento detallado del resto de la aplicación, serialización entre capas físicas, detalles de presentación, y acceso a base de datos, deben estar claramente separados de la implementación del dominio.
  • 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. 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. 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. 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. Ejemplos .Net http://code.google.com/p/ndddsample/ Java http://dddsample.sourceforge.net/
  • 19. Fin