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 obbliga a metterli insieme.
Troppo spesso osservo il seguente approccio
- Che figata che è Event Sourcing, lo dovrò sicuramente usare
- Lo userò per questo nuovo fiammante progetto di data entry
- Costruisco degli aggregati che fungano da command processor e persistono solo eventi, sono un purista io, mia micio micio bau bau
- Prendo questi eventi e li sparo su una coda con un bus, sono super figo
- Scodo e con dei denormalizzatori costruisco il modello in lettura così ho anche una bellissima implementazione di CQRS, che è come il prezzemolo sta bene ovunque
Lontani da sta gente, stare bisogna. Lasciando perdere ogni considerazione in merito vorrei però concentrarmi su un problema singolo: consistenza eventuale, aggregati e modello in lettura.
A prescindere dall’esempio volutamente forzoso di cui sopra, quando si ha a che fare con sistemi distribuiti complessi la consistenza eventuale è spesso un male necessario.
L’ossimoro
Perché è un problema? Perché ci troviamo di fronte ad un problema architetturale da non sottovalutare: in DDD gli aggregati sono la fonte unica della verità (single source of truth). Orbene, appena introduciamo un modello in lettura asincrono, e di conseguenza eventualmente consistente introduciamo una dicotomia rognosa che dobbiamo per forza gestire, non possiamo ignorare.
Se l’aggregato è la fonte della verità per il sistema è altresì vero che il modello in lettura è la fonte della verità per l’utente.
La cosa si complica ulteriormente quando dato un singolo aggregato abbiamo più modelli in lettura che possono avere inconsistenze diverse in un dato momento t, con la conseguenza che l’utente potrebbe essere ulteriormente spiazzato.
Le complessità introdotte, sia a livello di user experience che a livello tecnologico non sono banali e devono essere valutate molto bene a fronte della decisione di adottare un modello asincrono. Come dicevo ci sono situazioni in cui è pressoché inevitabile, ma in tutte quelle in cui si può evitare io personalmente lo eviterei. Del resto non siamo né Amazon né Google ma troppo spesso siamo convinti che le loro soluzioni siano l’ideale anche per noi.