CQRS

• Adoración González
• Ingeniero en Informática, UCM
• PHP Senior software developer
• @srtaDeveloper
• Coleccionista de
• elePHPantes
• Paracaidista
CRUD
Crear, leer, actualizar y borrar información
sobre un ÚNICO MODELO.
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)
CQRS - Esquema
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.
ConcreteOperationCommand
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.
ConcreteOperationCommandHandler
TIPOS DE ERRORES

1. Comandos inválidos.
2. Comandos válidos que generan estados

inválidos.
Procesamiento de un comando
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
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.
Query
Query Manager + Views Store Reader
Vista con información para el usuario.
Vista con info. para un bibliotecario.
“Ensamblando” modelos
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.
“Ensamblando” modelos
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.
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.
CQRS + Event Sourcing
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.
VENTAJAS

Responsabilidades bien definidas.

Posibles optimizaciones adecuadas a cada
modelo.

Mejora el rendimiento.

Facilita la escalabilidad.
INCONVENIENTES

Añade complejidad adicional al modelo de
negocio.

Dificultad para implementar la gestión de
la sincronización entre modelos.

Consistencia no inmediata.
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
GRACIAS :)
¿Preguntas?
Encuéntranos
https://www.meetup.com/PHPMad/

https://twitter.com/phpmad

https://www.youtube.com/user/phpmadri
d