The CQRSCQRS (Command Query Responsibility Segregation)Segregación de Responsabilidad de Comandos y Consultas. Es un patrón de arquitectura que separa explícitamente las operaciones de modificación de estado (Comandos, como crear o actualizar datos) de las operaciones de lectura (Consultas). Esta separación permite optimizar y escalar de forma independiente los modelos de datos de lectura y escritura, mejorando el rendimiento y la seguridad en sistemas complejos. (Command Query Responsibility Segregation) pattern proposes explicitly dividing a system's object model into two independent parts: one dedicated exclusively to processing state-changing operations (Commands) and another dedicated to resolving data queries and reads (Queries).
Formulated by Bertrand Meyer in his CQS (Command Query Separation) principle at the method level and scaled up to the architectural level by Greg Young, this pattern is fundamental for building highly scalable applications independent of traditional relational database bottlenecks.
1. The Single Data Model Problem
In conventional CRUD-style architectures, the same data model or ORM entityEntidad (Entity)El núcleo inamovible de la lógica de negocio en la Arquitectura Limpia. Una Entidad encapsula las reglas y datos empresariales más fundamentales y generales (las reglas de negocio críticas). Pueden ser objetos con métodos o un conjunto de estructuras de datos y funciones, y son completamente ajenas a cualquier cambio externo, como modificaciones en la base de datos, en el sistema de vistas o en el framework de desarrollo. is used for both writing and querying information.
This double responsibility generates multiple problems as the system grows:
- Load asymmetry: In most business applications, the volume of reads exponentially exceeds that of writes (e.g., in a 100:1 ratio).
- Complex queries and heavy DTOs: The write data model is usually highly normalized to guarantee transactional integrity, requiring expensive JOINs to present information in the user interface.
- Performance conflicts: Write transactions lock tables or rows while reads attempt to access the same records.
2. Separation into Two Independent Models
CQRSCQRS (Command Query Responsibility Segregation)Segregación de Responsabilidad de Comandos y Consultas. Es un patrón de arquitectura que separa explícitamente las operaciones de modificación de estado (Comandos, como crear o actualizar datos) de las operaciones de lectura (Consultas). Esta separación permite optimizar y escalar de forma independiente los modelos de datos de lectura y escritura, mejorando el rendimiento y la seguridad en sistemas complejos. solves this problem by decoupling the application into two specialized flows:
The Command Model (Write Model)
Focuses on executing business rules and system consistency. It receives user intentions expressed as imperative verbs (CreateOrderCommand, CancelSubscriptionCommand), validates business invariants through Use CasesCaso de Uso (Use Case)Estructura que define y representa una acción o flujo de negocio específico que un usuario o sistema puede realizar dentro de la aplicación. En Arquitectura Limpia, los Casos de Uso se ubican en la capa de aplicación y orquestan el flujo de datos desde y hacia las entidades, ejecutando las reglas de negocio específicas de la aplicación. Son completamente independientes de cómo se presentan los datos, de los frameworks y de los mecanismos de persistencia., and persists modifications in a database optimized for fast, transactional writes.
The Query Model (Read Model)
Focuses exclusively on offering the best reading experience for the client. It receives search parameters and returns DTOData Transfer Object (DTO)Objeto de transferencia de datos. Es un patrón de diseño de software cuyo propósito es transportar datos entre procesos o capas de una aplicación, sin contener lógica de negocio. En arquitecturas desacopladas como la Arquitectura Limpia, los DTOs se utilizan para transferir información de forma segura y fuertemente tipada desde los adaptadores externos (como controladores HTTP o comandos de consola) hacia los Casos de Uso en la capa de aplicación. Esto previene que el núcleo del sistema se acople a peticiones HTTP crudas o a estructuras de persistencia específicas. objects directly projected from denormalized data stores (such as Elasticsearch, Redis, or indexed SQL views). This model does not execute any business rules or modify state.
3. Synchronization and Eventual Consistency
Since the read and write models are separated, modified information in the command model must propagate to the read model.
This propagation is usually performed asynchronously using domain events. The period during which the read database reflects changes from the write database is known as eventual consistency.
In combination with Event Sourcing, CQRSCQRS (Command Query Responsibility Segregation)Segregación de Responsabilidad de Comandos y Consultas. Es un patrón de arquitectura que separa explícitamente las operaciones de modificación de estado (Comandos, como crear o actualizar datos) de las operaciones de lectura (Consultas). Esta separación permite optimizar y escalar de forma independiente los modelos de datos de lectura y escritura, mejorando el rendimiento y la seguridad en sistemas complejos. reaches its full potential, allowing you to reconstruct read projections from scratch by simply reprocessing the system's entire event history.
4. When to Apply CQRS?
CQRSCQRS (Command Query Responsibility Segregation)Segregación de Responsabilidad de Comandos y Consultas. Es un patrón de arquitectura que separa explícitamente las operaciones de modificación de estado (Comandos, como crear o actualizar datos) de las operaciones de lectura (Consultas). Esta separación permite optimizar y escalar de forma independiente los modelos de datos de lectura y escritura, mejorando el rendimiento y la seguridad en sistemas complejos. should not be used as a default pattern for all applications, as it introduces complexity to the infrastructure and the management of eventual consistency.
It is highly recommended in:
- Complex business domains where write logic differs radically from read views.
- High-performance systems where reads must scale independently from writes.
- Architectures based on Microservices and Clean Architecture.