Decisamente l’acronimo CQRS ultimamente è una delle buzzwords più in voga del momento e talvolta ci si scatenano dietro guerre di religione. In sostanza si parla di CQRS quando noi utilizziamo due modelli differenti, uno dedicato alla modifica dei dati (la parte di Commanding) ed uno dedicato alla lettura dei dati (la parte di query). Di base CQRS non è nemmeno un pattern, ma piuttosto una organizzazione architetturale che può essere declinata in tanti modi differenti, soprattutto in base alle necessità del progetto corrente (leggi requisiti). Approcciare un problema direttamente con CQRS+EVENT SOURCING+BLABLABLA senza che effettivamente ci sia...
Quando inizi a lavorare in ottica CQRS, ma più in generale quando ammetti che tra l’esecuzione di un comando e l’aggiornamento dell’UI presentata all’utente possa passare del tempo per cui la UI non riflette immediatamente il risultato del comando, ti chiedi se questa “limitazione” sia “vendibile” e “accettabile” dagli utenti ed in generale agli stakeholder del progetto. Molto spesso si parte prevenuti dicendo che non è ammissibile che un utente esegua l’operazione X e l’interfaccia rifletta l’effettivo risultato in ritardo, anche se solo dopo pochi secondi, oppure ancora peggio, che mostri i dati vecchi, ma è veramente cosi??? Durante...