CQRS

Meetup del 25/01/2017 para el grupo de usuarios PHP Madrid

Transcript

1. CQRS
2. • Adoración González • Ingeniero en Informática, UCM • PHP Senior software developer • @srtaDeveloper • Coleccionista de • elePHPantes • Paracaidista
3. CRUD Crear, leer, actualizar y borrar información sobre un ÚNICO MODELO.
4. CQRS Distinguimos 2 modelos que coexisten en una aplicación.  Modelo que crea, actualiza y borra. (Escritura)  Modelo que lee y consume información. (Lectura)
5. CQRS - Esquema
6. Modelo de Escritura-COMANDOS  Representan las operaciones que se pueden hacer.  Son DTOs de transporte de inputs entre cliente y la aplicación  Parámetros variables según tipo de operación.  Especificación basada en tareas.
7. ConcreteOperationCommand
8. SERVICIOS DE APLICACIÓN (HANDLER)  Ejecutan comandos  Contienen la lógica de negocio.  Validan reglas de negocio.  Realizan las operaciones concretas.  Llamadas a factorías y repositorios.  La lógica NO utiliza el modelo de lectura para obtener información.
9. ConcreteOperationCommandHandler
10. TIPOS DE ERRORES 1. Comandos inválidos. 2. Comandos válidos que generan estados inválidos.
11. Procesamiento de un comando
12. Concurrencia de Comandos  Ejecución concurrente de operaciones sobre una misma entidad.  Posibles operaciones inválidas en la aplicación.  Anticipar condiciones de carrera  Gestión de errores
13. Modelo de Lectura-Queries  Hacemos consultas sobre vistas ó proyecciones que contienen información de nuestro modelo.  Las vistas o proyecciones son estructuras ajustadas a la representación que queremos hacer de los datos. • Vistas de formularios, listados, reports…  Capa de lógica pequeña para gestionar las consultas y acceder a la infraestructura para leer.
14. Query
15. Query Manager + Views Store Reader
16. Vista con información para el usuario.
17. Vista con info. para un bibliotecario.
18. “Ensamblando” modelos
19. Sincronización y consistencia eventual. Problema: Cuanto tiempo pasa desde que se consolida el estado de una operación hasta que se actualizan las proyecciones de los datos.  El estado actual no está disponible inmediatamente.  Actualizaciones asíncronas.
20. “Ensamblando” modelos
21. CQRS + Event Sourcing Persistimos secuencia ordenada de eventos ocurridos en el modelo de escritura en lugar del estado actual de una entidad. UPDATE tabla_de_entidades SET estado = ‘delivered’ WHERE id = 589323  Unifica la forma en la que fluyen los datos entre un modelo y otro.  Conservamos todo el historial de operaciones sobre los agregados del modelo negocio.
22. CQRS + Event Sourcing l Eventos inmutables. l Parámetros variables dependiendo del tipo de evento. l Se persisten y no se borran. l No se modifican, si se necesitan más parámetros se cambia la versión del evento.
23. CQRS + Event Sourcing
24. Ideas importantes.  Adquirir una solución de compromiso entre la mejora de rendimiento y las necesidades de consistencia de nuestra aplicación. Y en base a eso decidir que estrategia seguir.  Si implementamos CQRS sobre una aplicación legacy hacerlo de forma incremental.  Si implementamos CQRS sobre DDD elegir el bounded context que requiera esta solución.
25. VENTAJAS  Responsabilidades bien definidas.  Posibles optimizaciones adecuadas a cada modelo.  Mejora el rendimiento.  Facilita la escalabilidad.
26. INCONVENIENTES  Añade complejidad adicional al modelo de negocio.  Dificultad para implementar la gestión de la sincronización entre modelos.  Consistencia no inmediata.
27. Referencias  http://udidahan.com/2009/12/09/clarified-cqrs/  https://martinfowler.com/bliki/CQRS.html  https://goodenoughsoftware.net/2012/03/02/cqrs/  http://danielwhittaker.me/  Ricardo Borillo - CQRS y los beneficios surgidos de la necesidad  Diego Moreno - Más allá del CRUD… (charla Codemotion 2016)  Implementing Domain Driven Design. Vaughn Vernon  Antonio J. García Lagar @ajgarlag
28. GRACIAS :) ¿Preguntas?
29. https://www.meetup.com/PHPMad/ Encuéntranos https://www.youtube.com/user/phpmadri d https://twitter.com/phpmad