CQRS I: Primer Vistazo

CQRS

Veremos un primer vistazo del patrón Command Query Responsability Segregation, un patrón utilizado para las aplicaciones con muchas transacciones en BD.

¿Qué es?

Básicamente, por un lado tenemos las Querys, que serán los datos que obtenemos directamente de BD (típica instrucción select para obtener datos) y por otra parte tenemos los Commands, que serían el InsertUpdate y Delete, que se ejecutan de forma asíncrona en otro proyecto para poder guardarlo.

¿Para qué sirve?

Como he comentado, es un patrón que sirve para aplicaciones con mucha actividad en BD, porque es muy rápido obteniendo datos, pero  tenemos que tener en cuenta que los Command, al ser asíncronos, se ponen en una cola donde pueden ser insertados al momento o demorarse un poco en persistirse.

Que utilizaremos

Vamos a usar MVC como ejemplo, esto es debido a que aprovechare esto para otros proyectos, y un propagador de eventos, túnel o Event Bus (RabbitMQ,…). De momento, solo será para las explicaciones, más adelante entraré más en detalle con las tecnologías usadas.

Bien, imaginemos que tenemos una pantalla donde tiene que aparecer un listado de usuarios. Para ello llamamos a una función del controller GetUsers(), y esta irá a nuestro proyecto de business (si lo tenemos), el cual tendrá acceso al DAL (nuestro proyecto con las querys) para obtener los datos. Hasta aquí todo normal.

La cosa es que cuando queremos persistir o borrar algún dato. Por ejemplo, modificamos un usuario y le damos a guardar, esto llamará a una función del controller, como podría ser UpdateUser(), la cual irá a nuestro proyecto de business, y este accederá a un repositorio que acabará publicando un evento en el Event Bus. Luego automágicamente (lo explicaremos más adelante con calma :)) lo recibiremos en un proyecto que tiene un Event Handler para capturar el evento, y este, lo persistirá en BD.

A grandes rasgos es así, en el siguiente gráfico se ilustra la arquitectura que sigue el patrón CQRS:

CQRS ejemplo del patron

CQRS ejemplo del patron

La BD

Ya que queremos una aplicación rápida, tenemos que plantearnos que BD utilizar. Podemos usar cualquiera, ya sea Oracle, SQL Server, MySQL, una documental (MongoDB, RavenDB,…), etc. Pero debido a la rapidez, optaremos por una documental, como he comentado, este patrón esta orientado a que sea muy rápido, y para ello las documentales son bastante más rápidas que una relacional, e incluso un SQL Server/Oracle con una no relacional.

Hay una comparativa muy interesante de Unai Zorrilla en su blog, donde realiza una inserción de 500k documentos en MongoDB en 1,6 segundos. Y por contra la respuesta de Pablo Alvarez en su blog también donde consigue bajarlo a 1,8 segundos en SQL Server.