Qué es CQRS y cómo separa lectura de escritura

Curso Profesional de Arquitectura de Software

Contenido del curso

Introducción al curso

1
Curso Profesional de Arquitectura de Software
02:36 min

Atributos de calidad

Patrones de arquitectura

Diseño de una arquitectura

Modelado y documentación de arquitectura

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:003:24

Qué es CQRS y cómo separa lectura de escritura

Curso Profesional de Arquitectura de Software

Clase 20 de 43

Clase 20 / 43

Recursos

Optimiza la lectura y la escritura con confianza usando CQRS: separa responsabilidades y gana velocidad sin perder el modelado del dominio. Cuando un único modelo no rinde bien para ambos escenarios, este enfoque permite crear modelos y hasta bases de datos distintas para cada necesidad.

¿Qué es CQRS y por qué separa lectura y escritura?

CQRS define la separación de responsabilidades entre consultas y comandos. La idea central: cuando es complejo optimizar lectura y escritura con un mismo modelo, conviene dividir en dos modelos e incluso en dos bases de datos. Así, el modelo de escritura se centra en persistir comandos, y el de lectura se optimiza para responder consultas con la mayor fluidez.

En aplicaciones enterprise con dominio estrictamente modelado, el diseño suele quedar optimizado para escritura. Sin embargo, en Internet predomina la lectura de alto volumen y la escritura puntual. Separar modelos permite mantener la calidad del dominio en la escritura y, a la vez, preparar los datos para la mejor lectura posible.

Separación de consultas y comandos para reducir fricción entre objetivos distintos.
Modelos de lectura y escritura diseñados con métricas de rendimiento diferentes.
Posibilidad de separar bases de datos según la carga y el acceso.
En Internet: mucha lectura y escritura ocasional.
Habilidad clave: detectar cuándo un único modelo no alcanza para optimizar ambos lados.

¿Cómo se aplica en reportes y e-commerce?

Un ejemplo práctico aparece en e-commerce: el administrador crea productos (escritura) y el consumidor los consulta (lectura). Para estos casos, los modelos pueden ser similares y funcionar bien. Pero los reportes de ventas combinan consumos de clientes y productos con otra lógica: están relacionados de forma lateral y no encajan de forma natural en el modelo de escritura.

Aplicar CQRS de forma puntual a reportes es útil cuando el esfuerzo de lectura para ajustarse al modelo transaccional es alto. Así se optimiza la lectura de reportes sin reestructurar toda la aplicación.

Escritura en un modelo transaccional para operaciones del negocio.
Lectura con un modelo preparado para agregaciones y consultas de reportes.
Uso selectivo de CQRS donde realmente aporta valor.

¿Cuándo aplicar solo en una parte del sistema?

Cuando el modelo de escritura sirve para operaciones transaccionales, pero no para consultas analíticas o de alto volumen. En esos casos, implementar CQRS únicamente en reportes reduce complejidad y mejora la performance de lectura.

¿Qué relación tiene con event sourcing y qué trade-offs existen?

Event sourcing recibe comandos y escribe eventos en una base de datos de eventos. Luego expone un modelo de lectura diferente: el estado actual. Por eso, es común que event sourcing incorpore o comparta el patrón CQRS: comandos generan eventos (escritura) y las consultas leen un estado derivado (lectura), cada uno optimizado para su propósito.

Escritura: eventos que registran cambios de forma inmutable.
Lectura: estado actual preparado para consultas.
Sincronía conceptual con CQRS al separar responsabilidades.

Ahora, los trade-offs. Mantener dos modelos y dos bases de datos tiene costos: hay que evolucionar ambos cuando aparecen nuevas funcionalidades o se detectan imprecisiones. No es un patrón universal, sino puntual: conviene adoptarlo cuando va a brillar en casos claros como reportes o altos volúmenes de lectura.

Costo de mantenimiento creciente al evolucionar dos modelos.
Complejidad operativa al sincronizar cambios y despliegues.
Habilidad clave: evaluar beneficio real antes de introducir la separación.

¿Dónde ves que CQRS aportaría más valor en tu contexto: reportes, catálogos, analíticas? Comparte tu caso y dudas en los comentarios.

Miguel Angel Reyes Moreno

Hace 2 años

Ejemplo de la estructura de directorios para un proyecto de generación de reportes utilizando el patrón CQRS (Command Query Responsibility Segregation). En este patrón, separamos la parte que se encarga de los comandos (escritura) de la parte que maneja las consultas (lectura). Esto permite una mayor optimización, escalabilidad y flexibilidad, especialmente en proyectos como la generación de reportes, donde la consulta de datos es frecuente.

/reporting-system

│

├── /command-side # Lado de comandos (Escritura)

│ ├── /src

│ │ ├── /domain # Lógica de negocio para la escritura

│ │ │ ├── /aggregates # Agregados del dominio

│ │ │ ├── /entities # Entidades del dominio

│ │ │ ├── /repositories # Interfaces de repositorios

│ │ │ └── /services # Servicios del dominio (escritura)

│ │ ├── /application # Capa de aplicación para comandos

│ │ │ ├── /commands # Comandos del sistema

│ │ │ └── /handlers # Manejadores de comandos

│ │ ├── /infrastructure # Capa de infraestructura

│ │ │ ├── /event-store # Almacenamiento de eventos

│ │ │ ├── /persistence # Implementaciones de repositorios

│ │ │ ├── /migrations # Migraciones de base de datos

│ │ │ └── /services # Servicios externos (colas, bases de datos, etc.)

│ │ └── /config # Archivos de configuración

│ ├── /tests # Pruebas unitarias y de integración

│ ├── Dockerfile # Configuración para Docker

│ ├── package.json # Dependencias del servicio de comandos

│ └── README.md # Documentación del lado de comandos

│

├── /query-side # Lado de consultas (Lectura)

│ ├── /src

│ │ ├── /domain # Lógica de negocio para la lectura

│ │ │ ├── /entities # Entidades del dominio de lectura

│ │ │ └── /repositories # Repositorios de lectura

│ │ ├── /application # Capa de aplicación para consultas

│ │ │ ├── /queries # Consultas del sistema

│ │ │ └── /handlers # Manejadores de consultas

│ │ ├── /infrastructure # Capa de infraestructura

│ │ │ ├── /read-database # Bases de datos de lectura

│ │ │ ├── /caching # Servicios de caché para optimización de lecturas

│ │ │ └── /services # Servicios externos (colas, bases de datos, etc.)

│ │ └── /config # Archivos de configuración

│ ├── /tests # Pruebas unitarias y de integración

│ ├── Dockerfile # Configuración para Docker

│ ├── package.json # Dependencias del servicio de consultas

│ └── README.md # Documentación del lado de consultas

│

├── /event-bus # Bus de eventos para comunicación entre lados

│ ├── /src

│ │ └── /subscribers # Subscriptores a eventos del sistema

│ ├── /tests # Pruebas del bus de eventos

│ ├── Dockerfile

│ ├── package.json

│ └── README.md

│

├── /common # Código compartido entre el lado de comandos y consultas

│ ├── /exceptions # Excepciones comunes

│ ├── /utils # Utilidades compartidas

│ ├── /events # Eventos compartidos entre comandos y consultas

│ └── README.md

│

├── /api-gateway # API Gateway que maneja peticiones HTTP

│ ├── /src

│ │ ├── /routes # Definición de rutas para comandos y consultas

│ │ └── /controllers # Controladores que manejan las rutas

│ ├── /tests # Pruebas del API Gateway

│ ├── Dockerfile

│ ├── package.json

│ └── README.md

│

├── /kubernetes # Archivos de configuración para Kubernetes

│ ├── /command-side.yaml # Configuración de despliegue para el lado de comandos

│ ├── /query-side.yaml # Configuración de despliegue para el lado de consultas

│ ├── /event-bus.yaml # Configuración de despliegue para el bus de eventos

│ └── /api-gateway.yaml # Configuración de despliegue para el API Gateway

│

├── /docker-compose.yml # Configuración de Docker Compose para desarrollo local

├── /README.md # Documentación general del proyecto

└── /package.json # Dependencias generales del proyecto (si las hay)

Explicación de la Estructura

Command-Side (Escritura):
- Este lado se encarga de las operaciones que modifican el estado del sistema, como crear, actualizar o eliminar reportes.
- Contiene:
  - Domain: Agregados, entidades, y lógica de negocio relacionada con la escritura.
  - Application: Comandos (como "Generar Reporte") y sus manejadores, que aplican cambios al sistema.
  - Infrastructure: Implementaciones de repositorios, almacenamiento de eventos, y servicios externos.
Query-Side (Lectura):
- Este lado se encarga de las operaciones que solo consultan datos sin modificar el estado, como obtener reportes o ver detalles.
- Contiene:
  - Domain: Entidades y lógica de negocio relacionada con la lectura.
  - Application: Consultas (como "Obtener Reporte por Fecha") y sus manejadores.
  - Infrastructure: Bases de datos optimizadas para lectura y mecanismos de caché.
Event-Bus:
- El bus de eventos maneja la comunicación entre los lados de comandos y consultas. Cada vez que se produce un cambio en el lado de comandos, se publica un evento que actualiza el lado de consultas (ej. "ReporteCreado").
API Gateway:
- El API Gateway es la puerta de entrada para las solicitudes HTTP. Maneja la redirección de comandos (escrituras) hacia el lado de comandos y de consultas (lecturas) hacia el lado de consultas.
Common:
- Contiene código compartido entre ambos lados, como excepciones, utilidades, y eventos comunes.
Kubernetes:
- Archivos de configuración para el despliegue en un entorno de orquestación como Kubernetes.
Docker Compose:
- Configuración para ejecutar los servicios de manera local utilizando contenedores Docker.

Ventajas de CQRS en Reportes

Escalabilidad: Puedes escalar independientemente el lado de escritura y el lado de lectura según las necesidades del sistema.
Optimización: Permite optimizar las consultas de lectura con bases de datos especializadas sin afectar la escritura.
Separación de responsabilidades: Facilita la gestión de la complejidad al dividir claramente las tareas de comando y consulta.

Comentarios (21)21 comentarios

Daniel Vaca

Hace 7 años

Elmer Padilla Espinoza

Hace 6 años

Victor Manuel Sarria Salinas

Hace 4 años

Carlos Eduardo Diaz Polanco

Hace 8 años

Pedro Jesus Hincapie Garcia

Carlos Enrique Ramírez Flores

Antonio Rafael González Ferrer

Mauricio Costanzo

Christian Gómez

Elizabeth Rosmery Ponce Pumacajia

Jenny Karen Guzmán Pulido

Andrés Madrigal

Adrian Trujillo Aquino

Abril Darynka Tapia Sosa

Andres David Sanchez

Hace 5 años

Daniel Adolfo Ordoñez Rubio

ANDRES ALFONSO MIRA MEJIA

Hace 3 años

Victor Daniel Aguirre Gil

Alejandro Picado Brenes

Kevin Toruño

Liliana Colls

Zalo Testa

Juan Carlos Ortiz Romero

Camilo Cadavid

Platzi

Roberto Iván Pineda Hernández

Hace un año

Jonathan Crespo

Introducción al curso

Curso Profesional de Arquitectura de Software

Atributos de calidad

Qué son los atributos de calidad en software

Cómo medir idoneidad funcional en software

Qué es eficiencia de ejecución en software

Cómo medir interoperabilidad y coexistencia

Qué es la usabilidad y sus 6 dimensiones

Cómo medir confiabilidad en software

Los 5 pilares de seguridad en software

Cómo garantizar mantenibilidad con tests

Adaptabilidad vs capacidad de instalación vs reemplazo

Tensiones entre atributos de calidad de software

Atributos de calidad según fase de empresa

Patrones de arquitectura

Qué es un patrón de arquitectura

Modelo vista controlador: cómo separar responsabilidades

Arquitectura en capas: controller, servicio y repositorio

Event sourcing vs bases relacionales

Qué es la arquitectura microkernel

Arquitectura Comparte Nada con Map Reduce

Patrón de microservicios: cuándo y cómo

Qué es CQRS y cómo separa lectura de escritura

Arquitectura hexagonal: puertos y adaptadores

Qué son los contextos delimitados en DDD

Cómo combinar patrones de arquitectura

Evolución de patrones desde monolito a microservicios

Diseño de una arquitectura

Cómo traducir requerimientos en decisiones arquitectónicas

Conectores en arquitectura: tipos y cuándo usarlos

Llamadas asíncronas vs síncronas vs cliente-servidor

Conector enrutador vs difusión: Twitter

Conectores cola, repositorio y pub/sub

Framework de diseño orientado a atributos

Cómo detectar fallas y reparar sistemas

Cómo recuperar y prevenir fallas en sistemas

Tácticas para confinar modificaciones

Cómo prevenir efectos dominó en software

Tácticas para controlar eficiencia de ejecución

Cómo detectar, resistir y recuperarse de ataques

Cómo probar que el software funciona correctamente

Cómo controlar la usabilidad con tácticas

Cómo validar arquitectura con ATAM y métricas

Evolución de arquitectura: startup a gran escala

Modelado y documentación de arquitectura

Cómo documentar arquitectura que no se erosione

Cómo sincronizar arquitectura y código fuente

Cómo aplicar atributos de calidad en proyectos

Qué es CQRS y cómo separa lectura de escritura