En este artículo vamos a poner de manifiesto las características de dos patrones de arquitectura, que pese a no ser nuevos están adquiriendo peso en el panorama tecnológico actual, debido principalmente a su buena disposición para la escalabilidad, resiliencia, responsividad y comunicación asincrona. En otras palabras, cumplen con los requisitos principales de un sistema reactivo. 

Command query responsibility segregación (CQRS) es un patrón de arquitectura que se fundamenta en la separación entre la persistencia de datos y la consulta de los mismos. Esta característica supone la aplicación del principio de única responsabilidad(SRP), que tantos sistemas monolíticos incumplen (en algunos casos por falta de necesidad o por utilizar frameworks orientados a CRUD), y que garantiza que estas dos responsabilidades con requisitos tan distintos puedan cumplir con los mismos de forma autónoma. De esta manera, los sistemas que aplican este diseño, están constituidos por dos subsistemas completamente independientes: el de consultas y el de comandos. Ambos módulos del sistema  presentan diseño, modelo de datos y paradigma de persistencia distintos, optimizados para cada necesidad, aunque obviamente deben estar conectados entre sí y esto se realiza mediante sincronización.

El módulo de consultas es bastante más sencillo y suele estar compuesto por una primera fase de filtrado y transformación , de la información que le llega del módulo de comandos vía sincronización , para a continuación consolidarla en su modelo de datos orientado a que las consultas sean óptimas y que suele ser SQL o NO SQL, dependiendo de la necesidad.

El módulo de comandos es el receptor de las peticiones y del procesamiento de las mismas. Cada petición que es procesada supone un cambio de estado del sistema y tiene asociada un proceso de sincronización que hará posible que el módulo de consulta sea poseedor de la información(por PULL,PUSH o como sea).

Al profundizar en las diferentes maneras de diseñar el módulo de comandos es cuando entra en juego Event Sourcing.

El patrón de arquitectura Event Sourcing se fundamenta en una premisa: Toda la información del sistema debe estar vinculada a sus estados y debe guardarse como una secuencia ordenada de eventos, siendo un evento el mecanismo que posibilita un cambio de estado del sistema.

Este paradigma rompe con los modelos de datos relacionales y con el patrón ORM ya que no es necesario persistir las entidades ni relacionarlas entre si. Solo basta con tener una secuencia ordenada de eventos serializados ya que esto contiene toda la información del sistema. Los tipos de repositorio para almacenar la información que mejor encajan son: sistemas No Sql orientados a documentos como MongoDB, sistemas clave valor como Redis o incluso escritura en fichero (hay que tener en cuenta que solo existe inserción no aplica ni borrado ni actualizaciones) y también sería posible una BBDD SQL tradicional aunque no es lo más óptimo.

Volviendo a la sincronización entre los módulos de consulta y comandos, vemos ahora que la situación más óptima es la solicitud desde el subsistema de consultas de los eventos persistidos desde la última sincronización o en caso de producirse algún problema podría reestablecerse desde un estado anterior o incluso desde el origen.

Pues con todo esto estamos en disposición de apreciar las importantes ventajas que supone combinar los patrones de arquitectura CQRS y event sourcing.

  • Escalabilidad
  • Resilencia
  • Responsividad
  • Comunicación asíncrona
  • Rendimiento
  • Recuperación y reestablecimiento del sistema en caso de fallo o        pérdida de información en el módulo de consultas.
  • Sistema de auditoría avanzado de serie( intrínseco en el diseño )

Vemos que a diferencia de los sistemas monolíticos, CRQS y event sourcing encaja perfectamente con una arquitectura moderna que garantice la alta disponibilidad(24×7) , buenos tiempos de respuesta, seguridad y robustez.

De entre los frameworks existentes que adoptan estos patrones de arquitectura cabe destacar Axon 4 .

Debido a que el objetivo de este articulo es introducir los conceptos, características y cualidades de los patrones arquitectónicos CQRS y Event Source desde una perspectiva conceptual, no quiero hacerlo demasiado denso incluyendo un ejemplo práctico, que por otro lado tiene multiples y variados modos de implementación. Eso sí, queda pendiente para un próximo artículo.