Este documento presenta una charla sobre el patrón arquitectónico CQRS/ES (Command Query Responsibility Segregation/Event Sourcing). Explica que CQRS separa las consultas de los comandos y que el Event Sourcing almacena los cambios de estado como una secuencia de eventos en lugar de estados actuales. También describe los beneficios de este enfoque como el aislamiento, la escalabilidad y la disponibilidad, así como conceptos clave como comandos, eventos, consistencia eventual y almacenamiento de eventos.

1. Foro de arquitectos 2015
CQRS/ES - Cambiando tu forma de pensar

2. ¿Quienes Somos?

3. https://www.desarrollaconmicrosoft.com/dotnetspain2015

4. Sobre todo esta es una charla seria sobre escalabilidad, eh???

5. Bertrand Meyer (via Wikipedia)
“Command Query Separation”
“every method should either be a command that performs an action,
or a query that returns data to the caller, but not both. In other words,
asking a question should not change the answer.”
¿CQS? ¿Pero esto no iba de CQRS?

6. ■ “Command Query Responsibility Segregation”
■ Es un patrón que se basa en el principio CQS.
■ No es una arquitectura, es un patrón.
¿Qué es CQRS?

7. CQRS como táctica de guerra

8. ■ Aislamiento
■ Agilidad
■ Pruebas
■ Mantenimiento
■ Escalabilidad
■ Disponibilidad
■ ...
Beneficios de usar CQRS

9. CQRS por un niño de 10 años

10. CQRS en serio

11. ■ El 90% del acceso a nuestras aplicaciones son consultas
■ Muy rápidas
■ Cachealas!
■ Consitencia eventual
Consultas

12. ■ Aplicable a todo el sistema o solo a una parte (Base de datos)
■ Es lo opuesto a la consistencia de datos
■ Es una característica natural de los sistemas distribuidos y escalables
Consistencia eventual

13. Teorema de CAP

14. ■ Son directivas del dominio para ejecutar una acción
■ Pueden ser rechazados por el dominio (Validaciones/Negocio)
■ Puede dar resultado a 0:n eventos
■ Siempre en imperativo
■PlaceOrder, no OrderPlaced
■ Un manejador por commando
■ Pueden ser encolados
Comandos

15. Perdiendo el miedo a los comandos
public class PlaceOrderCommand
{
//properties
public readonly Guid OrderId;
public readonly string Comment;
//ctor
public PlaceOrderCommand(Guid id, string comment)
{
OrderId = id;
Comment = comment;
}
}

16. ■ Son el resultado de una acción que ha ocurrido en el dominio
■ Nunca pueden ser rechazados
■ Siempre en pasado
■ OrderPlaced, no PlaceOrder
Eventos

17. ■Captura todos los cambios de estado que se produce en nuestra
aplicación como una secuencia de eventos en el orden en que
suceden.
■No modelo entidad/relación o modelo de objectos.
■Tenemos todo el historial de operaciones realizadas frente a lo que se
conoce como “last-known good state”.
■No es una arquitectura independiente.
■Casa perfectamente con DDD y CQRS.
¿Qué es Event Sourcing?

18. ID Modified … State
1 26/01/2015 … Pending
¿Cómo funciona?
Sistema tradicional
Event Sourcing
ID Modified … State
1 28/01/2015 … Cancelled
1 27/01/2015 … Approved
1 26/01/2015 … Pending
ID Modified … State
1 27/01/2015 … Approved
ID Modified … State
1 28/01/2015 … Cancelled

19. ¿Cómo funciona?

20. ■Es una base de datos para almacenar eventos:
■GetEventStore – http://geteventstore.com
■NEventStore – http://neventstore.org
■Base de datos relacional (JSON)
■Base de datos documental
Event Store

21. ■Volviendo a ejecutar los eventos (Replay Events)
Pero… ¿Qué ocurre si tenemos que volver a ejecutar eventos para saber cual es el
estado de nuestra cuenta bancaria? ¿Qué pasa si la abrimos hace 10 años?
Podemos encontrarnos con problemas de rendimiento al tener que ejecutar miles de
eventos…
¿Cómo podemos solucionar esto?
¿Cómo reconstruimos el estado de la aplicación?

22. ■Para evitar tener que ejecutar miles de eventos para reconstruir el estado de
nuestra aplicación se usan Data Snapshots.
■Cada x eventos guardamos el estado actual de nuestra aplicación. (Caché)y
podemos hacer un replay de eventos desde es momento.
Data Snapshots

23. Probablemente no 
¿Debería usar CQRS/ES?

24. ¿Preguntas?

25. Gracias!