Overview

¿Qué es CQRS?

El patrón de Command Query Responsibility Segregation es, como su nombre lo indica, un patrón de diseño de software que separa las actividades escritura de las actividades de consulta. En el lenguaje CQRS, un command escribe datos en una fuente de datos. Una query lee datos de una fuente de datos. CQRS aborda el problema de la degradación del rendimiento del acceso a los datos cuando las aplicaciones que se ejecutan a escala web tienen demasiada carga sobre la base de datos física y la red en la que reside.

Ejemplo sistema tradicional

Si el rendimiento comienza a degradarse, siempre puede convertir la base de datos única en un clúster de base de datos y así distribuir las actividades de acceso en todo el clúster. Sin embargo, siempre que el clúster estuviera expuesto como un solo punto en la red, aún existía el riesgo de una latencia alta debido al cuello de botella alrededor de ese punto de acceso. Todas las solicitudes de lectura (la consulta) y todas las solicitudes de escritura (el comando) fueron al mismo destino.

El beneficio que aporta CQRS al diseño de datos es que separa los comportamientos de lectura y escritura en la aplicación de forma lógica y física.

Segregación de Lectura/Escritura

Cuándo usar el patrón

Considere CQRS para los siguientes escenarios:

• Dominios colaborativos donde muchos usuarios acceden a los mismos datos en paralelo. CQRS le permite definir comandos con suficiente granularidad para minimizar los conflictos de fusión a nivel de dominio, y los conflictos que surgen pueden fusionarse con el comando.

• Interfaces de usuario basadas en tareas donde los usuarios son guiados a través de un proceso complejo como una serie de pasos o con modelos de dominio complejos. El modelo de escritura tiene una pila de procesamiento de comandos completa con lógica empresarial, validación de entrada y validación empresarial. El modelo de escritura puede tratar un conjunto de objetos asociados como una sola unidad para cambios de datos (un agregado, en terminología DDD) y garantizar que estos objetos estén siempre en un estado coherente. El modelo de lectura no tiene lógica comercial ni pila de validación, y solo devuelve un DTO para usar en un modelo de vista. El modelo de lectura es finalmente consistente con el modelo de escritura.

• Escenarios en los que el rendimiento de las lecturas de datos debe ajustarse por separado del rendimiento de las escrituras de datos, especialmente cuando el número de lecturas es mucho mayor que el número de escrituras. En este escenario, puede escalar horizontalmente el modelo de lectura, pero ejecutar el modelo de escritura en solo unas pocas instancias. Un pequeño número de instancias de modelo de escritura también ayuda a minimizar la aparición de conflictos de fusión.

• Escenarios en los que un equipo de desarrolladores puede centrarse en el modelo de dominio complejo que forma parte del modelo de escritura y otro equipo puede centrarse en el modelo de lectura y las interfaces de usuario.

• Escenarios en los que se espera que el sistema evolucione con el tiempo y pueda contener varias versiones del modelo, o donde las reglas comerciales cambian con regularidad.

• Integración con otros sistemas, especialmente en combinación con el abastecimiento de eventos, donde la falla temporal de un subsistema no debería afectar la disponibilidad de los demás.

Este patrón no se recomienda cuando:

• El dominio o las reglas comerciales son simples.

• Basta con una sencilla interfaz de usuario de estilo CRUD y operaciones de acceso a datos.

Para más información consultar CQRS