Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Domain driven desing
Similar a Domain driven desing (20)
Domain driven desing
- 2. En un enfoque tradicional de diseño… DOMAIN DRIVEN DESING Presumimos que los casos de uso son suficientes para que… …los ingenieros de software construyan un sistema.
- 3. En un enfoque tradicional de diseño… DOMAIN DRIVEN DESING Presumimos que los casos de uso son suficientes para que… …los ingenieros de software construyan un sistema.
- 4. DOMAIN DRIVEN DESING PERO NO SON SUFICIENTES
- 5. ¿De que se trata DDD? DOMAIN DRIVEN DESING Es un enfoque de desarrollo de software para necesidades complejas enfocado en conectar profundamente la implementación con un modelo de negocios en constante evolución partiendo de la base del trabajo en equipo, la comunicación y colaboración constante entre expertos técnicos (Ingenieros de Software) y expertos del dominio (Usuarios) en contextos acotados de negocio utilizando para ello un lenguaje ubicuo “El software puede fallar por dos motivos: creamos las cosas mal o creamos las cosas incorrectas”
- 6. Para implementar DDD: DOMAIN DRIVEN DESING • Lo primordial es mantener contacto constante y permanente con el experto del negocio utilizando un lenguaje ubicuo • Mapea los dominios y sepáralos en subdominios • Mira el panorama general del Proceso de Negocio As Is, aprendiendo sobre el dominio del problema • Crea contextos acotados (Bounded Contexts) entre subdominios • Idealmente, debe haber un equipo, una base de código y una base de datos diferentes para cada uno de los Bounded Contexts • Dado que todos estarían trabajando dentro de su propio Bounded Context, serían libres de cambiar cualquier cosa dentro de este (siempre trabajando con los Expertos del Dominio y utilizando Lenguaje Ubicuo) • Para todos los asuntos transversales que se comparten entre diferentes Bounded Contexts (lo llamamos Shared Kernel), cualquier cambio debe ser conocido y acordado entre todos los equipos en cada Bounded Context afectado (nuevamente, teniendo en cuenta que los equipos son conformados entre los expertos técnicos de sistemas y los expertos del domino del negocio) • Mantente siempre enfocado en los comportamientos del dominio en lugar del estado del dominio (favorece un modelo rico sobre un modelo anémico)
- 7. ¿Y qué no debemos hacer al implementar DDD? DOMAIN DRIVEN DESING 1. Tener una vista centrada en los datos al modelar el dominio del problema. Por lo general, el modelo de datos es lo primero que un arquitecto o ingeniero de software comenzará a diseñar. Siempre consideran que los datos son lo más importante porque los datos son todo lo que necesitamos informar. Con DDD, debemos cambiar este paradigma. Los datos en sí mismos no tienen sentido. Sólo la lógica da a los datos un significado, y los mismos datos pueden tener un significado diferente en contextos diferentes. Por lo tanto, debemos comenzar con contexto y lógica en lugar de datos
- 8. ¿Y qué no debemos hacer al implementar DDD? DOMAIN DRIVEN DESING 2. Centrarse en los detalles de la implementación como entidades, objetos de valor, servicios, fábricas y repositorios en lugar de los conceptos básicos del negocio. Las entidades, los objetos de valor, los repositorios, etc., no tienen un significado hasta que definimos el lenguaje ubicuo, los contextos delimitados y las interfaces. Si comenzamos pronto con los detalles de implementación como las entidades, entonces es muy probable que el resultado sea un dominio anémico rodeado de una gran cantidad de servicios y lógica empresarial dispersos por todas partes, que generan a su vez DEUDA TÉCNICA.
- 9. ¿Y qué no debemos hacer al implementar DDD? DOMAIN DRIVEN DESING 3. Usar términos y conceptos genéricos o técnicos de desarrollo al implementar la aplicación. Nunca debemos usar conceptos como save, update, delete, handle, manage, etc. Esos conceptos son conceptos técnicos/abstractos y sin un significado específico para el usuario. En cambio, debemos mantenernos enfocados en los conceptos de negocio. Los conceptos mencionados anteriormente (es decir, save, update, etc.) no están relacionados con los conceptos de negocios.
- 10. ¿Y qué no debemos hacer al implementar DDD? DOMAIN DRIVEN DESING 4. Sobreestimar las transacciones de bases de datos en lugar de centrarse en los procesos y transacciones comerciales. En DDD, las transacciones comerciales son más importantes que las transacciones de Bases de Datos. Las transacciones de Bases de Datos son ACID, muy consistentes y de corta ejecución, mientras que las transacciones comerciales no lo son. De hecho, en la vida real solo conocemos las transacciones comerciales. Nunca pensemos en transacciones DB. En su lugar, siempre pensemos en los procesos del mundo real, en las acciones (comportamientos) y sus posibles resultados, y cómo compensar las acciones si se producen fallas.
- 11. ¿Y qué no debemos hacer al implementar DDD? DOMAIN DRIVEN DESING 1. Tener una vista centrada en los datos al modelar el dominio del problema. 2. Centrarse en los detalles de la implementación como entidades, objetos de valor, servicios, fábricas y repositorios en lugar de los conceptos básicos del negocio. 3. Usar términos y conceptos genéricos o técnicos de desarrollo al implementar la aplicación. 4. Sobreestimar las transacciones de bases de datos en lugar de centrarse en los procesos y transacciones comerciales.
- 13. ¿Lenguaje Ubicuo, eso con que se come? DOMAIN DRIVEN DESING
- 14. ¿Y el contexto acotado? DOMAIN DRIVEN DESING CONTEXTO DE LA VENTA CONTEXTO DEL SOPORTE
- 15. Modelado Conceptual Estratégico en DDD DOMAIN DRIVEN DESING
- 17. Modelado Conceptual Táctico en DDD DOMAIN DRIVEN DESING
- 18. Diseño Estratégico DOMAIN DRIVEN DESING Diseño Táctico • AGREGADOS • ENTIDADES • OBJETOS DE VALOR • SERVICIOS Y EVENTOS DEL DOMINIO • REPOSITORIOS • FACTORIAS • ARQUITECTURA
- 19. El Meta Modelo Conceptual DOMAIN DRIVEN DESING
- 21. Arquitectura en Capas y Microservicios DOMAIN DRIVEN DESING Presentation Layer API Layer Domain Layer Infraestructure Layer