CQRS
Quando ci aspettiamo di generare più di un modello in lettura a fronte di una singola modifica le cose diventano un filino più complesse di quelle che abbiamo descritto fino ad ora. Il commento di Fabio centra appieno uno dei problemi: Supponiamo uno scenario del tipo: Cerco un cliente in anagrafica Non lo trovo tra i risultati Pigio il pulsante “Nuova anagrafica cliente” Creo il cliente Torno ai risultati della ricerca Il punto [5] è quello...
Qualcuno potrebbe giustamente obiettare che ogni volta che abbiamo a che fare con HTTP, essendo un protocollo disconnesso, abbiamo uno scenario che ha problematiche simili a quello asincrono che abbiamo descritto. Aggiungo io che ogni volta che abbiamo a che fare con uno sistema che non usa lock pessimistici in lettura abbiamo a che fare con uno scenario simile.
In realtà le problematiche sono due, molto diverse tra loro, ma entrambe da comprendere e maneggiare con cura e consapevolezza.
Concorrenza ottimistica
Lo scenario a prescindere da come viene generato il modello in lettura è:
richiesta HTTP in GET
...
Mi capita troppo spesso di osservare implementazioni di CQRS prese troppo alla leggera, con conseguenti (tanti tanti) buchi che fanno acqua da tutte le parti. Soprattutto quando, spesso senza che ve ne sia una vera necessità, l’implementazione comporta consistenza eventuale tra modello in scrittura e modello in lettura. Quello che spesso osservo è un pastrocchio di concetti che tendono a fare di tutta l’erba un fascio e una soluzione che deve per forza portare con se concetti e pattern architetturali che nessun dottore ha mai detto debbano andare per forza insieme. Stanno bene insieme, ma nessuno ci...
Questo me l’ero perso per strada tempo fa. Ne è passata di acqua sotto i ponti da quella serie su CQRS: “C” come CQRS: una possibile implementazione dei comandi CQRS: eventualmente consistente “QRS” come CQRS CQRS: “A” come de-normalizzazione asincrona CQRS: “C” come “Conversation Id” Siccome il tema mi sembra ancora attuale ha comunque senso darvi un paio di risorse per approfondire: Powering front end apps with NServiceBus Connect frontend to backend using SignalR and...
Una strana corrente di pensiero dice che CQRS porta con se la necessità di andare d’accordo con la consistenza eventuale perché il modello in lettura è asincrono, con l’ovvia conseguenza che ci vediamo costretti a portarci a casa un bus di qualche tipo per far si che modello in scrittura e modello in lettura siano allineati. Concedetemi il francesismo: balle :-) CQRS si limita a postulare che il canale di scrittura e il canale di lettura devono essere diversi. Fine, punto e capo. Cosa ci vieta quindi di avere un repository...
Se abbiamo detto che sincrono e asincrono sono la stessa cosa, su quale base possiamo ritenere affidabile il modello in lettura? Abbiamo però anche detto che il modello in lettura è la verità per l’utente, o in maniera più generica, per il chiamante. Ripartiamo da dove ci siamo fermati: chiedere al sistema l’elenco di tutti i clienti insolventi; se vi sono clienti involventi; avviare una pratica di recupero crediti con tutti i clienti insolventi; Quale dovrebbe essere l’approccio? chiedere al...
Trovo più interessante insistere su questo punto, piuttosto che sulla separazione tra canale di scrittura e canale di lettura. Le query in CQRS non cambiano la verità. Ci sono due informazioni importantissime in quella affermazione: cambiamento e verità. Se l’unico modo per avere informazioni è attraverso una query sul modello in lettura significa che il modello in lettura rappresenta la verità. Questo in apparenza è in netto contrasto con il concetto di Aggregato di DDD, che è il detentore della verità e delle invarianti, e dal punto di vista CQRS il destinatario di comandi. Quello che...
I due acronimi, DDD e CQRS, stanno troppo spesso nella stessa frase e sempre più spesso mi rendo conto che per le persone devono andare a braccetto: nulla di più sbagliato. DDD ha uno scopo, per certi versi molto filosofico e aulico, che gira intorno al concetto di comprensione e/o processo di apprendimento, DDD si prefigge di permetterci di disegnare un modello di dominio che sia il più fedele possibile al modello analitico che vogliamo maneggiare. Il modello analitico è frutto del processo di apprendimento, o di analisi, che una serie di attori, i domain expert(s) (notare il...
Qualche tempo fa con un amico si stava discutendo di `Repository Pattern` e di tutto quello che gli gira intorno, tutta la disquisizione ruotava intorno a quale fosse il ruolo di un `repository` in un mondo orientato a CQRS. Siamo dopo un po’ di scambi di opinioni giunti alle seguenti questa conclusioni. Un repository deve consentire di caricare un aggregato data la sua chiave primaria; consentire di aggiungere una nuova istanza di un aggregato; persistere le modifiche apportate ad un aggregato; rappresentare una...
Ora che //BUILD ha ufficialmente sdoganato anche in casa Microsoft due concetti fondamentali come Microservices e DevOps è definitivamente giunto il momento di capire come far si che le nostre architetture siano adeguate, pronte e/o adeguabili a questo nuovo mondo che si sta spalancando davanti ai nostri occhi. Quello dei microservices è ad oggi un mondo alquanto fumoso, c’è ancora molta discussione su cosa sia un microservice, se in questa confusione ci mettiamo pure tanta nuova tecnologia, una su tutte Docker, che sta per invadere, o ha già invaso le nostre macchine, le cose si fanno ancora più complicate....
Full CQRS Archive