Issue 10009
CQRS e read model: separare solo quando la lettura ha davvero un altro ritmo
Quando il modello di lettura migliora chiarezza e performance, e quando invece aggiunge solo complessità operativa.
· 5 min
Obiettivo
Decidere quando separare modelli di comando e di lettura migliora chiarezza, performance o autonomia, e quando invece aggiunge complessità operativa non necessaria.
Quando CQRS ha senso in pratica
CQRS non è una scelta da fare perché "fa enterprise". Ha senso quando il lato di scrittura e il lato di lettura hanno esigenze diverse in modo sostanziale: regole di dominioGlossarioDominioLa parte del mondo reale, del business o dell’organizzazione che un sistema deve supportare.Apri la voce completa forti sul comandoGlossarioComandoUna richiesta rivolta a uno specifico owner perché tenti di eseguire un’azione.Apri la voce completa, query molto più numerose o complesse, necessità di viste denormalizzate per il consumo, oppure autonomia tra team e confini applicativi che non devono dipendere dallo stesso modello. Il punto operativo è semplice: se il modello di dominio è ottimo per garantire correttezza delle scritture ma pessimo per rispondere alle query, un read modelGlossarioRead ModelUna rappresentazione dei dati modellata per una specifica query o esigenza utente.Apri la voce completa separato può ridurre attriti, semplificare le query e migliorare le performance percepite. Ma prima di separare, chiediti se il problema è davvero il modello oppure solo una query mal progettata, un indice mancante o un confine di servizio confuso. Un buon testGlossarioTestUna verifica deliberata che produce evidenze su una specifica aspettativa o rischio.Apri la voce completa da fare in review architetturale è questo: il team di lettura può evolvere la propria vista senza toccare le regole di scrittura? Se la risposta è sì, CQRS può portare chiarezza. Se la risposta è no, stai probabilmente introducendo duplicazione senza un beneficio reale. • Usa CQRS quando lettura e scrittura hanno volumi, modelli o responsabilità davvero diversi. • Conserva il write model focalizzato su invarianti, validazioni e consistenza di dominio. • Tratta il read model come una vista ottimizzata per il consumo, non come una seconda fonte di verità.
I trade-off da dichiarare senza ambiguità
Il vantaggio principale di CQRS è la separazione netta delle responsabilità: il write model protegge il dominio, il read model serve le query in modo efficiente. Questo può migliorare prestazioni, leggibilità del codice e autonomia organizzativa. Il costo, però, è concreto. Introduci duplicazione di dati o proiezioni, sincronizzazione tra modelli, eventuale consistenza eventuale, logiche di replay o ricostruzione, e una superficie operativa più ampia da monitorare. Anche il troubleshooting cambia: quando il dato letto non coincide con l'ultimo comando, devi sapere se sei in ritardo, se c'è un errore di proiezione o se stai osservando uno stato intermedio legittimo. In altre parole, CQRS non elimina la complessità: la sposta dal modello unico a un sistema di aggiornamento e lettura più articolato. Per questo il pattern va giustificato con un beneficio verificabile, non con una preferenza estetica. • Gain: query più semplici e più veloci sul lato lettura. • Gain: write model più pulito e vicino al dominio. • Loss: più componenti, più osservabilitàGlossarioOsservabilitàLa capacità di comprendere il comportamento di un sistema a partire dai segnali che produce.Apri la voce completa richiesta, più casi di inconsistenza temporanea. • ConseguenzaGlossarioConseguenzaUn effetto atteso, positivo o negativo, di una decisione.Apri la voce completa: il team deve saper spiegare come si riconciliano ritardi, errori di proiezione e stati incerti.
Esempio enterprise: ordini, stato e supporto clienti
Immagina una piattaforma retail con picchi di traffico durante campagne commerciali. Il comando "crea ordine" deve applicare regole di dominio precise: disponibilità articoli, limiti di credito, coerenza dello sconto, stato del cliente. Quel flusso richiede un write model affidabile e controllato. Dall'altra parte, il customer service e il front-end hanno bisogno di vedere subito la cronologia ordini, lo stato di evasione, le spedizioni e gli eventuali blocchi. Qui un read model denormalizzato, alimentato da eventi o proiezioni, può offrire query molto più semplici e veloci rispetto a interrogare direttamente il dominio di scrittura. Ma il contratto operativo deve essere esplicito: se un ordine è stato accettato ma la proiezione non è ancora aggiornata, il supporto deve sapere che la vista può essere temporaneamente indietro. Questo si collega bene ai failure contract e alla distinzione tra errori tecnici, errori di business e stati incerti: non tutto ciò che sembra "mancante" è davvero un errore funzionale. • Il write model governa la correttezza del comando. • Il read model serve una consultazione veloce e leggibile per business e supporto. • La semantica dello stato deve includere ritardi e ambiguità, non solo il caso felice.
Per approfondire
Riferimenti esterni autorevoli per approfondire CQRS, read model e trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa di progettazione. • CQRS pattern - Microsoft Azure Architecture Center - https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs • Designing Data-Intensive Applications - Martin Kleppmann - https://dataintensive.net/