CQRS (Command Query Responsibility Segregation) es un patrón propuesto por Greg Young que separa, dentro de un mismo bounded context, el modelo de escritura del modelo de lectura. Las operaciones que cambian estado (commands) pasan por un modelo de dominio rico con validaciones e invariantes; las operaciones que consultan datos (queries) pasan por un modelo de lectura optimizado, típicamente denormalizado para que cada vista responda con una sola consulta.
La motivación es real: las necesidades de escritura y de lectura son diferentes. Escribir requiere consistencia, validaciones, transacciones; leer requiere rapidez, agregaciones, formato específico para UI o reporting. Forzar el mismo modelo para ambos suele acabar en compromisos malos: agregados complejos para servir pantallas que solo necesitan tres campos, o joins enormes que penalizan cada lectura.
CQRS no implica obligatoriamente bases de datos distintas; en su forma sencilla basta con tener servicios/clases separadas para commands y queries dentro de la misma BD. En su forma avanzada se combina con event sourcing y se mantienen proyecciones separadas (incluso en bases de datos distintas: Postgres para escribir, Elasticsearch para buscar, una vista materializada para reporting) actualizadas asíncronamente vía eventos. Esto da rendimiento brutal en lectura a cambio de eventual consistency.
En 10Code aplicamos CQRS de forma medida. En la mayoría de proyectos basta con separar Application Services de Query Services (mismo BD), lo que ya aporta claridad arquitectónica. Solo escalamos a proyecciones físicamente separadas cuando el rendimiento o la complejidad de las lecturas lo justifica, y siempre asumiendo explícitamente eventual consistency con el cliente.
En 10Code llevamos más de una década aplicando estas tecnologías a productos reales. Si quieres comentarnos tu caso, escríbenos y te respondemos personalmente.
Hablar con un ingeniero