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....
Vi ricordate quando da piccoli giocavate, e magari come me lo fate ancora :-), con il LEGO? Nel 2009 dicevo, quotando me stesso: Se modelliamo il nostro mondo in tanti piccoli, magari molto piccoli e molto tanti…, componenti che collaborano otteniamo un modello complesso, probabilmente molto complesso, ma facilmente testabile, manutenibile, evolvibile, etc… Al tempo il concetto era molto più in linea con il single responsibility principle che con le architetture distribuite ma se oggi mettiamo insieme quel concetto con le potenzialità offerte da una metafora come il LEGO e troviamo qualcosa che...
La serie di post su CQRS si arricchisce sempre più, ne mancano un paio per chiudere il cerchio e avere una overview abbastanza completa su “cosa”, “come” e “quando”. L’ultima volta che ne abbiamo parlato abbiamo introdotto il concetto di de-normalizzazione asincrona, elencando più o meno una lista di possibili passi simile a quella che segue: Invio del comando in POST; Ricezione del comando e dispatch dello stesso su una coda; Invio della risposta HTTP-202; Ricezione del comando e...
Nelle nostre divagazioni su CQRS di qualche tempo fa abbiamo parlato di eventualmente consistente ma non ci siamo addentrati nelle implicazioni tecniche che eventualmente consistente porta con se. Qualche, più di qualche, divagazione tecnica la approfondisco sul mio blog in inglese parlando di Jason che è un toolkit che ho scritto per eliminare dai pensieri dello sviluppatore tutta la parte infrastrutturale. In uno scenario come il seguente però abbiamo un piccolo problema nel momento in cui la parte di de-normalizzazione è asincrona: Supponendo una Single Page Application in cui i comandi arrivano via HTTP avete il...
Qualche giorno fa sono stato da un cliente per una giornata di consulenza, giornata che in partenza sembrava prospettarsi come la solita, senza nessuna connotazione negativa sia chiaro, giornata in cui si discute di tecnologia, ma mai aspettativa fu più sbagliata. La giornata partiva con l'obiettivo di capire come migrare un'architettura tradizionale, quindi basata su layer, verso un'architettura esagonale corredata da CQRS e Event Sourcing, partendo dal presupposto che il team si era già fatto tutta una serie di domande, sacrosante, che aprivano a molti dubbi sulla scelta che si stava per fare. n.d.r.: il...
...e le conseguenti pessime decisioni di design. Sto lavorando con le API di amministrazione dell’ACS di Windows Azure, API che sono esposte oltre che dal portale di Azure con una bella e comoda interfaccia anche come servizi in modo da poter programmaticamente gestire la configurazione. I servizi che l’ACS di Azure espone sono basati su OData (almeno in apparenza) ed espongono un modello apparentemente molto comodo, sempre in apparenza :-) Osservate il seguente stralcio di codice: var client = CreateManagementServiceClient();
var parties = client.RelyingParties;
foreach ( var party in parties )
{
Console.WriteLine(...
L’organizzazione delle due giornate di corso procede e da pochi minuti siamo live anche con la pagina di registrazione su EventBrite: http://implementing-cqrs.eventbrite.it/ Per una questione meramente logistica vi chiedo, per qualsiasi informazione, di utilizzare il modulo di contatto di EventBrite, che gira internamente su una mailing list e vi offre quindi molte più chance di ricevere una risposta in tempi ragionevoli. Ci sono altre novità in arrivo, stay tuned! .m
Aria di novità in Managed Designs, stiamo organizzando il primo corso interamente dedicato a CQRS basato sull’esperienza concreta, e quotidiana, maturata sui progetti che stiamo portando avanti presso i nostri clienti. Obiettivo delle 2 giornate di formazione sarà sviscerare tutte le componenti di CQRS e tutte le problematiche che possono emergere quando si applica un pattern architetturale a scenari reali; ovviamente faremo anche un’interessante divagazione su alcuni concetti fondanti di DDD, concetti necessari per poter apprendere a fondo tutti gli aspetti di questo approccio. Una bozza di agenda, con gli argomenti in ordine ancora sparso, è la seguente:...
Tutte le volte che mi capita di parlare con qualcuno di CQRS o di sentire qualcuno parlare di CQRS ho la sensazione che ci si concentri troppo su quella che a mio modo di vedere è la parte meno importante tra le due componenti: i comandi; portare l’architettura verso un modello basato su comandi è fondamentale, sia chiaro, perché ci aiuta a modellare in maniera estremamente più semplice il modello mentale dell’utente, cosa che ci consente di fare un balzo in avanti eccezionale, ma i comandi sono anche la novità del momento e la “C” di CQRS sta oscurando quella...
Qualche giorno fa in “C come CQRS” abbiamo analizzato, senza scendere troppo nel dettaglio, una possibile implementazione della parte di comandi di CQRS. Ora, quello che abbiamo ricade a tutti gli effetti sotto il cappello dei tecnicismi, che, sono si importanti, ma senza avere una visione generale del problema trovano il tempo che trovano. Se ci spostiamo un pelo più in alto e diamo uno sguardo al tutto quello che vediamo, generalizzando molto e prendendo la letteratura alla lettera, è questo: Ci sono tante implementazioni possibili, anche molto più semplici di quella identificata nel diagramma,...
CQRS che…? per una esaustiva introduzione a CQRS potete leggere questo articolo di Martin Fowler. Andrea nella sua sessione su CQRS al .NETCAMPUS presentando il pattern, e una possibile implementazione, ha detto una cosa importantissima, particolarmente vera quando si parla in generale di Domain Driven Design: CQRS, Event Sourcing e DDD sono una metodologia di sviluppo che aggrega vari pattern architetturali, ognuno dei quali, in fase di implementazione, può essere declinato in modi diversi tutte egualmente giusti, in dipendenza del contesto in cui ci troviamo. (non sono le esatte parole, ma rendono...