Separación de comandos y consultas

Un problema habitual es que al tener una base de datos relacional, por ejemplo, puede ser rápida para escritura pero lenta para lectura (Al requerir joins entre tablas) pero una base de datos noSQL podría ser rápida para lectura al tener los datos en una sola consulta en formato JSON, podríamos plantear la alternativa de aprovechar ambas opciones y tener dos bases de datos optimizadas PERO nos enfrentamos al gran problema de mantener SINCRONIZADAS las bases de datos.

Dependiendo de la velocidad que necesitamos mantener la sincronización de la información podemos usar varias alternativas:


Arquitectura:


La sincronización puede ser una problema, pero puede ser mitigada con la técnica de Event Sourcing. Se refiere en que los datos son almacenados como una secuencia de eventos, en lugar de guardar el estado actual del sistema.

Eventos

Los beneficios de realizar un Event Sourcing + CQRS es por un lado la independencia del sistema de sincronización, ya que no es necesario llamar el servicio de syn directamente para activarlo de tal manera que el Command Stack genera eventos y el sistema de sincronización los consume. Y por otro lado, la traducciones de eventos son más sencillas que traducir toda una entidad.

✅ Tratamiento independiente de las lecturas y las escrituras, y teniendo bases de datos adecuadas (normalizadas / desnormalizadas) para cada situación permitiendo escalar las soluciones de forma independiente.