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 il vostro normale utilizzo da Utenti software fate caso a quanti siti importanti utilizzano questo paradigma. Prendiamo E-bay; stamattina mi connetto, debbo lasciare due feedback, uno degli item è arrivato, quindi lascio il feedback solo su quello poi torno sul “il mio ebay” e … ho ancora due feedback da lasciare, vabbè, faccio un paio di ricerche, passano cinque minuti buoni, torno sul “il mio ebay” e la pagina è ancora cosi
A questo punto magari mi sorge il sospetto che il sistema prima non abbia accettato il feedback (nonostante mi abbia detto che era stato preso in carico) per cui clicco per lasciarlo ancora, ma il sistema mi notifica che qualche cosa non va.
In ottica DDD molto probabilmente la UI che visualizza “il mio ebay” non è stata ancora notificata dell’avvenuto feedback, per cui mi presenta ancora il link per farlo, chiaramente quando tento di farlo ancora e vado su una UI che probabilmente è pertinente del Bounded Context dei Feedback mi trovo che la UI è aggiornata e mostra chiaramente che l’operazione richiesta non è disponibiole. Probabilmente il denormalizzatore che gestisce “il mio ebay”, (il cui compito è attendere il DOMAIN EVENT FeedbackDone, ed in base ad esso aggiornare il numero di feedback che l’utente deve lasciare) ha priorità minore, forse il sito era carico, forse fisicamente il feedback ha richiesto tempo per essere eseguito, etc etc. Non mi interessano i dettagli, ma piuttosto che il sistema utilizzi chiaramente paradigmi CQRS e che mi stia mostrando dati vecchi (stale)
Ora torniamo a quello che dicevo prima sul fatto che questa “limitazione” sia “vendibile” e “accettabile”. La prima considerazione è che questa non è una limitazione, anzi è una funzionalità che aumenta la scalabilità. Se mi soffermo a pensare perché “il mio ebay” mostri ancora 2 feedback mi viene da pensare che magari il sistema sia molto carico al momento, oppure magari la “tabella dei feedback” è in lock per un upgrade.. o chissà cosa, ma il mio feedback è stato preso comunque in carico dal sistema, anche se il resto del sistema non è stato notificato/aggiornato. Se volessi un sistema che non ammette la visualizzazione di dati stale, dovrei attendere durante il postback del feedback che tutte le UI siano aggiornate e magari farlo in transazione, questo fa si che dopo 5 minuti ancora vedrei la pagina caricarsi perchè non riesce ad aggiornare “il mio ebay”? Oppure non posso lasciare feedback se per qualche ragione ho un lock nella tabella dei feedback per un upgrade: inaccettabile. Un sistema che non ammette di mostrare dati vecchi (se è in un picco di carico o in un upgrade oppure ha dei lock perchè in quel momento sta girando un processo o per qualsiasi ragione) è un sistema che prima o poi diventerà lento, l’utente premerà il bottone “lascia il feedback”, dopo 30 secondi ancora la pagina è in caricamento ed avremo un utente frustrato
L’ammettere che le UI possano essere stale permette al sistema di rispondermi immediatamente dicendo “il tuo feedback è stato preso in carico”, punto. Il fatto che poi tutto il sistema Ebay si accorga di questo in ritardo per me non è importante, importa che il comando e la mia azione siano state prese in carico ed in modo molto veloce. Ragionare a Command / Handler in ottica CQRS rende il mio sistema molto scalabile e soprattutto molto User Task oriented. L’utente deve essere semplicemente “avvertito” di questo funzionamento, in modo che quando guarda i dati, è conscio che su qualcuno di essi si possa essere formata della muffa (dati stale).
Appurato che questa struttura non è una “limitazione” ma semplicemente una struttura per aumentare la scalabilità ragioniamo sull’”accettabile” da parte degli utenti. Il mio consiglio è che prima di dire “non è accettabile” si faccia uno studio reale dei requisiti, per capire se è compatibile con i suddetti e soprattutto si intervistino gli utenti per capire come la pensano e come verrà usato il sistema. In un sistema su cui lavoro, il fatto di fare un upgrade in background ed essere notificati in differita sul risultato è stato una grande miglioria, perché il sistema era più responsivo. Il vedere per un po’ di secondi dati vecchi non era assolutamente un problema, ma invece di attendere 10 secondi per l’esecuzione di complesse operazioni di business su un dato, il sistema risponde in pochi millisecondi dicendo all’utente “ho inziato l’elaborazione” e l’utente viene avvertito in modo esplicito solamente in caso di fallimento (raro) perchè deve prendere azioni correttive. L’utente è più contento, accetta che il risultato sia visibile in differita, ed è più felice.
Insomma, siamo nel 2012, e sempre più i sistemi informatici attorno a noi sono realizzati su questi paradigmi ed ammettono che sia normale visualizzare dati vecchi e sempre più gli utenti saranno abituati a questo paradigma, e anzi, forse riterranno inaccettabile un sistema che blocca la UI per 4 secondi scrivendo “updating” commentando: “che schifo, perché non potrebbe fare sto lavoro in background e notificarmi in differita in caso di problemi?”, quindi probabilmente saranno le strutture “tradizionali” ad essere “inaccettabili” :).
Meditate gente, meditate.
Gian Maria
