CQRS
Separar el modelo de lectura del modelo de escritura en vez de usar un único modelo para ambos.
Qué resuelve
Los comandos (escritura) validan reglas de negocio e invariantes; las consultas (lectura) solo proyectan datos para la UI.
Permite optimizar lectura y escritura por separado: el modelo de escritura prioriza consistencia, el de lectura prioriza velocidad de consulta.
Es independiente de Event Sourcing — se puede aplicar CQRS con una base de datos relacional normal, sin event store.
Cuándo tiene sentido
El dominio tiene lógica de escritura compleja (validaciones, invariantes) mientras que las lecturas son mayormente de reporte/listado.
Las cargas de lectura y escritura son muy distintas en volumen o forma, y escalarlas juntas es ineficiente.
Compensaciones
Más piezas móviles: dos modelos (o más) que mantener sincronizados en vez de uno.
Si se combina con proyecciones asíncronas, introduce consistencia eventual — la UI puede mostrar datos desactualizados por un instante.
Para un CRUD simple es sobre-ingeniería: el costo de la separación no se paga solo si no hay complejidad de dominio real.
Comentarios