Así pues, en un sistema informático de un comercio online se podrían encontrar microservicios de clientes, facturas, productos, pedidos, ventas, proveedores… Cada microservicio tendría su propio modelo de datos, donde representa la información que le hace falta. Claro está, a medida que avanza el desarrollo, los modelos pueden volverse más complejos, por lo que es necesario establecer ciertas barreras lógicas tangibles. Estas barreras son lo que se conocen como Bounded Context y limitan qué información pertenece a un dominio u otro. Cada Bounded Context puede contener ciertos procesos de negocio o gestión de eventos por lo que, desde un punto de vista técnico, un Bounded Context podría contener más de un microservicio.

Ahora bien, los modelos crecen, se vuelven complejos y es en este contexto donde hay que empezar a plantearse la separación de las funcionalidades de lectura y escritura.

Patrón

Command Query Responsibility Segregation (CQRS) es un patrón arquitectónico introducido por Greg Young que junto al Diseño Dirigido por Dominio (DDD), se utiliza en el diseño de sistemas basados en microservicios. CQRS está basado en el principio de Separación de Consultas y Comandos ideado por Bertrand Meyer por el cual, un objeto tendría métodos separados para consultas y para escritura de datos; pero va más allá, considerando que hay dos modelos: uno para escrituras y otro para lecturas.

Se puede considerar un patrón basado en comandos y eventos y, opcionalmente, en mensajes asincrónicos. Puede incluso haber dos bases de datos (dos modelos no implican necesariamente dos bases de datos), una de actualizaciones y otra de lectura, y se seguiría el siguiente esquema:

Figura 1: Subsistemas de Escritura y Lectura físicamente separados.

En sistemas CQRS más evolucionados se llega a implementar Event Sourcing, esto es, que cada evento es almacenado en el orden en que ocurrió, de tal manera que los eventos pueden ser consultados, utilizados para restaurar el estado del sistema o para volver atrás mediante operaciones “deshacer”.

Ventajas

• Permite seguir más de cerca el principio de responsabilidad única. Lectura y escritura son procesos relacionados pero diferentes, y tener mecanismos bien diferenciados permite mantener mejor los modelos.
• Si los subsistemas de escritura y lectura se separan físicamente, podrían escalarse de manera independiente.
• Las tecnologías de ambos sistemas podrían ser distintas: el sistema de escritura podría tener una base de datos distinta de la de lectura.
• Las consultas se vuelven más sencillas.

Inconvenientes

• Aumenta la complejidad del sistema haciendo complicado la creación de software Reentrante (capacidad de poder interrumpir la ejecución de una rutina y volver a llamar dicha rutina de forma segura (re-entrar), antes de que acaben las invocaciones anteriores) y multihilo.
• Si se utiliza Event Sourcing, la complejidad aumenta.
• Problemas de transaccionalidad pueden llevar a incoherencias de datos, ya que un usuario podría consultar datos obsoletos.

José Luis Antón Bueso, Solution Architect en Altia.