CQRS

CQRS e molteplici modelli in lettura

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...

posted @ Wednesday, January 10, 2018 4:27 PM | Feedback (0)

CQRS e modello in lettura: quali alternative abbiamo?

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 ...

posted @ Thursday, January 4, 2018 10:45 AM | Feedback (4)

Quando la verità non è una sola: CQRS, consistenza eventuale, e utenti

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...

posted @ Friday, December 29, 2017 2:19 PM | Feedback (0)

CQRS: “N” come “notifiche”

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...

posted @ Wednesday, October 26, 2016 11:56 AM | Feedback (0)

Falsi miti: il modello in lettura di CQRS è asincrono

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...

posted @ Wednesday, December 16, 2015 9:34 AM | Feedback (1)

Come faccio a fidarmi del modello in lettura di CQRS?

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...

posted @ Wednesday, September 30, 2015 10:35 AM | Feedback (0)

Le query in CQRS non cambiano la verità.

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...

posted @ Tuesday, September 15, 2015 10:10 AM | Feedback (2)

Falsi miti: CQRS va implementato con DDD e DDD senza CQRS non si può fare

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...

posted @ Tuesday, July 28, 2015 10:17 AM | Feedback (0)

Repository delle mie brame

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...

posted @ Wednesday, June 17, 2015 9:44 AM | Feedback (2)

Microservices, containers, nano server, fabric…oh my…

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....

posted @ Monday, May 4, 2015 10:30 AM | Feedback (1)

Full CQRS Archive