CQRS es una herramienta muy buena a la hora de programar. Es realmente una ayuda y puede llegar a facilitarte muchas cosas, sigue leyendo y aprende todo sobre CQRS.
¿Qué es CQRS?
CQRS es un patrón arquitectónico, donde el acrónimo significa Segregación de Responsabilidad de Consulta de Comando (o Command Query Responsibility Segregation, en inglés). Podemos hablar de CQRS cuando las operaciones de lectura de datos se separan de las operaciones de escritura de datos y ocurren en una interfaz diferente.
En la mayoría de los sistemas CQRS, las operaciones de lectura y escritura utilizan diferentes modelos de datos, a veces incluso diferentes almacenes de datos. Este tipo de segregación hace que sea más fácil escalar, leer y escribir operaciones y controlar la seguridad, pero agrega complejidad adicional a tu sistema.
Node.js at Scale, es una colección de artículos que se enfocan en las necesidades de las empresas con instalaciones más grandes de Node.js y desarrolladores avanzados de Node.
El nivel de segregación puede variar en los sistemas CQRS:
- Almacenes de datos únicos y modelo separado para leer y actualizar datos.
- Almacenes de datos separados y modelo separado para leer y actualizar datos.
En la separación más simple del almacén de datos, podemos usar réplicas de solo lectura para lograr la segregación.
¿Por qué y cuándo usar CQRS?
En un sistema de administración de datos típico, todas las operaciones de CRUD (crear actualización de lectura eliminada) se ejecutan en la misma interfaz de las entidades en un solo almacenamiento de datos. Como crear, actualizar, consultar y eliminar filas de tablas en una base de datos SQL a través del mismo modelo.
CQRS realmente brilla en comparación con el enfoque tradicional (utilizando un solo modelo) cuando construye modelos de datos complejos para validar, y cumplir su lógica empresarial cuando ocurre la manipulación de datos. Las operaciones de lectura en comparación con las operaciones de actualización y escritura pueden ser muy diferentes o mucho más simples, como acceder solo a un subconjunto de sus datos.
Un ejemplo muy vívido
En nuestra herramienta de monitoreo Node.js , usamos CQRS para segregar el almacenamiento y la representación de los datos. Por ejemplo, cuando ve una visualización de seguimiento distribuido en nuestra interfaz de usuario, los datos detrás de ella llegaron en trozos más pequeños de los agentes de aplicaciones de nuestros clientes a nuestra API de recopilador público.
En la API del recopilador, solo hacemos una validación delgada y enviamos los datos a una cola de mensajería para su procesamiento. En el otro extremo de la cola, los trabajadores consumen mensajes y resuelven todas las dependencias necesarias a través de otros servicios. Estos trabajadores también están guardando los datos transformados en la base de datos.
Si ocurre algún problema, devolvemos el mensaje con un retroceso exponencial y un límite máximo a nuestra cola de mensajería. En comparación con este complejo flujo de escritura de datos, en el lado de la representación del flujo, solo consultamos una base de datos de réplica de lectura y visualizamos el resultado para nuestros clientes.
CQRS y su fuente de eventos
He visto muchas veces que las personas están confundiendo estos dos conceptos. Ambos son muy utilizados en infraestructuras dirigidas por eventos como en micro-servicios controlados por eventos, pero tienen significados muy diferentes.
Base de datos de informes – Denormalizer
En algunos sistemas controlados por eventos, CQRS se implementa de manera que el sistema contiene una o varias bases de datos de informes.
Una base de datos de informes es un almacenamiento de solo lectura completamente diferente que modela y conserva los datos en el mejor formato para representarlos. Está bien almacenarlo en un formato des-normalizado para optimizarlo para las necesidades del cliente. En algunos casos, la base de datos de informes solo contiene datos derivados, incluso de múltiples fuentes de datos.
En una arquitectura de microservicios, llamamos a un servicio Denormalizer si escucha algunos eventos y mantiene una base de datos de informes basada en estos. El cliente está leyendo la base de datos de informes del servicio desnormalizado.
Un ejemplo puede ser que el servicio de perfil de usuario emita un evento user.edit con información útil { id: 1, nombre: 'Mary Anne', Estado: 'churn' }, el servicio Denormalizer lo escucha, pero solo lo almacena en su Base de datos de informes { nombre: 'Mary Anne' }, porque el cliente no está interesado en el estado churn interno del usuario.
Puede ser difícil mantener una base de datos de informes sincronizada. Usualmente, solo podemos apuntar a la consistencia eventual .
Outro
CQRS es un poderoso patrón arquitectónico para segregar las operaciones de lectura y escritura y sus interfaces, pero también agrega complejidad adicional a su sistema. En la mayoría de los casos, no debe usar CQRS para todo el sistema , solo para partes específicas donde la complejidad y la escalabilidad lo hacen necesario.
Para leer más sobre las bases de datos de informes y CQRS, recomiendo revisar los siguientes recursos:
- CQRS – Martin Fowler
- CQRS – MSDN
- CQRS, UI basadas en tareas, ¡Fuente de eventos de nuevo! – Greg Young
- CQRS y fuente de eventos – Code on the Beach 2014 – Greg Young
- Base de datos de informes – Martin Fowler
¡Felicidades por haber finalizado esta lección!
