CQRS (Command Query Responsibility Segregation) es un patrón arquitectónico que separa las operaciones de lectura y escritura en una aplicación, usando modelos de dominio separados y posiblemente bases de datos separadas. Esto permite mejor escalabilidad y rendimiento al poder optimizar de forma independiente las consultas y comandos. CQRS sigue el principio SOLID de responsabilidad única aplicado a nivel de arquitectura.

1. CQRS
Command Query Responsibility Segregation
Jornada de Arquitectura .NET - 2º Edició
sábado, 7 de septiembre de 2019
Fernando Sonego
Solution Architect in Algeiba

3. Muchachos tuve una
idea extraordinaria
que revolucionara al
mundo ¡¡¡Dividamos los
modelos de consulta
de los demás!!!
¿Eso no es
CQRS?
Si, lo presento
Greg Young el
año pasado

4. ¿Qué es CQRS?
• Es un patrón bastante simple de entender.
• La Idea es en lugar de tener un modelo unificado, necesitamos tener 2,
uno para lectura y otro para escritura.
• Las principales características dicen que cada método debe ser un
comando o un consulta que solo haga una acción, pero no ambas cosas.
• Los comandos son del tipo Void.
• El patrón ayuda a la legibilidad del código, con un golpe de vista
podemos ver su propósito por su firma.
• CQRS extiende el principio de CQS a nivel arquitectura.
• CQRS fue presentado Greg Young en el año 2010, el se baso en la idea
Single Responsibility Principle correspondiente a SOLID.
Sorry for
thinking it
first

5. Command Query Responsibility
Segregation
Clientes
Modelo de
dominio
Consultas de
Lectura
API
Escritura
API
Lectura
DB
Relacional
DB No
Relacional
Sync
Comando Comandos
consulta Consultas

6. ¿Y porque usar CQRS?
Escalabilidad Rendimiento Simplicidad

7. Escalabilidad
Crear Leer Actualizar Eliminar
Crear
Leer
Actualizar Eliminar

8. Escalabilidad | Rendimiento | Simplicidad
Crear
Actualizar
Eliminar
Leer
Comandos
1 Servidor
Consultas
10 Servidores
Consultas SQL
altamente optimizadas
Cache
Solo cambian datos
Reducción de código
complejo

9. En resumen
• CQRS nace a partir de CQS.
• CQRS extiende CQS a nivel arquitectocnico.
• Separa un modelo unificado en 2 partes: una de lectura y otra de escritura.
• CQRS nos permite tomar diferentes decisiones para las lecturas y
las escrituras.
• Mejor escalabilidad.
• Mejor Performance.
• Código Simple.
• CQRS es SRP (Single Responsability Principle) aplicado a nivel de
arquitectura.

10. Go to the Action
Code

11. Hablemos un poco mensajes
• En CQRS en realidad vamos a tener 3 tipos de mensajes
• Comandos, le dice a la aplicación que tiene que hacer algo.
• Consultas, le pregunta a la aplicación por algo.
• Eventos, información para externos.
Clientes
Aplicación
Comando
consulta
Eventos
Externos

12. Clean Code
• Convenciones de nombres
Comandos EventosConsultas
En imperativo
EditContactInfo
Empezar con Get
GetList
Pasado
ContactInfoChanged
NO! EditContactInfoComand GetListQuery ContactInfoChangedEvent

13. Problemas en la arquitectura de dominio
Clientes
Modelo de
dominio
Servicios
App
Servicios
App
API
API
• Modelo de dominio complicado
• Transporte pesado de datos
innecesarios
• Mala rendimiento para las
consultas

14. ¿Entonces voy a tener 2 modelos de
dominio en DDD?
Clientes
Comandos
Consultas
DDD aquí
DDD no aquí
• Donde no hay modificación de datos
• No necesitamos encapsulación.
• No necesitamos abstracciones.

15. ¿Qué otra cosa no debo hacer?
Clientes
Comandos
Consultas
No usar ORMs

16. No usar ORMs en lecturas
• ¡Pero tengo el lazy load activado!
• Cuando esta activosy necesitamos acceder a la base de datos se vuelve a
consultar ( bye bye perfomance).
• ¡Bueno lo desactivo!
• Tampoco no hace falta esta medida extrema.
• Conclusión
• Solo usar un grande y pesado ORM con comandos.
• Escribir a mano las consultas SQL.

17. Aumentemos el rendimiento y la
escalabilidad
Clientes
Comandos
Consultas
Master
Replica 1
Replica 1
Replica
Mismo problema, separamos las lecturas, pero
seguimos con los mismos modelos.

18. Pensemos un minuto
¿Que forma tienen la mayoría del tiempo los
datos de consulta?
DESNORMALIZADOS

19. ¡Desnormalizada! ¿Y que hago entonces?
• Podemos crear tablas especializadas de consultas que se actualicen
por un trigger en la base de datos.
• Podemos, en el caso de SQL, usar vistas especializadas para las
consultas.
• Podemos crear una base de datos especializada total mente para
consultas para consultas.
• Podemos usar indexadores o bases de datos NoSQL.

20. Resumen sobre las bases de datos
• Bases de datos separadas para consultas
• Podemos implementar completo el patrón
CQRS.
• Las lecturas y escrituras están separadas
en cada nivel: API, servicios de
aplicaciones, modelo de dominio, base de
datos.
• Ajustar las lecturas de base de datos al a
necesidad real del modelo de consulta.
• Escalabilidad se da agregando recursos
de servidor
• Ejemplos de separación en el nivel de
base de datos:
• Vistas indexadas
• Replica de base de datos
• Algunas herramientas como Elastic Search.
• Diseñar la base de datos para lecturas
• Desnormalizar y ajustado a las
necesidades del modelo real.
• Reducir el numero de Joins y muchísimo
pos-procesamiento.
• La tercera forma normal es para
comandos, la primera mejor para
consultar.
• Podría necesitar una base de datos de
lectura separada para cada cliente.
• Mantener la sincronización es costoso;
eventual inconsistencia es confusa:
• en muchos casos, una sola base de datos
es suficiente

21. Tarea para hogar
• Commandos Vs DTOs.
• Sincronización de comandos y consultas:
• Proyecciones impulsadas por estados.
• Proyecciones manejadas por manejadores de eventos.
• Consistencia.
• Consistencia Eventual.
• Versionado.
• Expedición de cache
• CQRS vs Patrón Especificación
• Handlers Vs Decoradores Vs Middleware

22. Conclusiones y Preguntas

23. Fernando Sonego
Solution Architect
fernando.sonego@gmail.com
@FernandoSonego
www.withoutdebugger.com
Jornada de Arquitectura .NET
2º Edición
sábado, 7 de septiembre de 2019