vOpenUy: El misterioso CQRS

1. uy.vopen.tech

2. El misterioso CQRS
Command Query Responsibility Segregation
Fernando Sonego
Solution Architect

4. 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

5. ¿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.
• CQRS fue presentado Greg Young en el año 2010, el se baso en la idea
Single Responsibility Principle correspondiente a SOLID.
• Las principales características dicen que cada método debe ser un
comando o un query que solo haga una acción, pero no ambas cosas.
• 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.

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. 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

11. Go to the Action

12. 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

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

14. 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

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

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

17. 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.

18. 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.

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

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

21. Resumen sobre las bases de datos
• Bases de datos separadas para consultas
• Podemos implementar completo el patron
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

22. Go to the Action

23. Info
• https://github.com/fsonego/vOpenUyCQRS
• dotnet restore
• dotnet build
• dotnet run

24. 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

25. Conclusiones y Preguntas

26. SPONSORS

27. ¡Gracias!
fernando.sonego@gmail.com
@FernandoSonego
www.withoutdebugger.com
Fernando Sonego
Solution Architect