Il y a cinq ans, CQRS revenait en réunion et je ne comprenais pas de quoi on parlait. Des livres sur le sujet, il y en a. Un guide Microsoft de 2012 sur Windows Azure, un pavé de 650 pages avec du Kotlin, un booklet de 72 pages, deux livres de DDD à vingt ans d'écart. Aucun ne dit par lequel commencer, et l'ordre change tout.
Je les ai lus, je fais de l'Event Sourcing au quotidien, et j'ai écrit une fiche de lecture pour chacun. Voici l'ordre que je donnerais, et ce que tu peux sauter.
Commence par le DDD, mais pas par Evans
L'Event Sourcing et le CQRS répondent d'abord à un problème de modélisation, et seulement ensuite à un problème technique. C'est Learning Domain-Driven Design de Vlad Khononov (2021, 8,6/10) qui me les a posés dans leur vrai cadre, au lieu de les présenter comme des gadgets à la mode. Le chapitre qui vaut le prix, c'est l'annexe : Khononov y raconte sa propre startup, « où nous avons commis toutes les erreurs de DDD possibles ». On part de « des agrégats partout » et on finit à « de la langue commune partout ».
Le blue book d'Eric Evans (2003, 7/10) reste la fondation. Le vocabulaire (Bounded Context, Aggregate, Ubiquitous Language) vaut à lui seul le déplacement. Mais tout est en Java de 2003, et on ne le lit pas d'un bout à l'autre : on ouvre le chapitre qui correspond au problème du moment. Pour retrouver une définition, la DDD Reference (6,4/10) tient en soixante pages gratuites. C'est un glossaire, pas un cours : utile seulement si tu connais déjà le terrain.
Le seul qui montre la facture
Exploring CQRS and Event Sourcing (Microsoft patterns & practices, 2012, 200 pages, 8,2/10) est le plus vieux de la liste et le plus honnête. La plupart des introductions vendent les bénéfices et passent la plomberie sous silence. Celui-ci te force à regarder le coût avant de t'engager : deux fois plus de temps que prévu, cohérence éventuelle dans l'interface, publication atomique entre le store et le bus.
Son chapitre sur les Sagas vaut la lecture à lui seul. J'ai vu la confusion entre Process Manager et Saga produire de vraies erreurs d'architecture : des équipes qui montent de la machinerie de transactions compensatoires pour un flux qui vit entièrement dans un seul bounded context. Le guide dissipe ça en dix pages. La limite à assumer : le code d'exemple cible Windows Azure en 2012. Lis-le pour les idées, ne le copie pas.
Le gros livre, en deux moitiés
Understanding Eventsourcing de Martin Dilger (2024, 650 pages, 7,5/10) a deux visages. La première moitié, Foundations et Modeling, est ce que j'ai lu de plus clair sur l'Event Sourcing et l'Event Modeling : la métaphore de la boîte de jouets, le completeness check, la différence entre événements internes et Integration Events. J'aurais voulu l'avoir il y a cinq ans.
La seconde moitié est une autre planète. L'implémentation avec Axon, en Kotlin, suppose un écosystème Spring/Java que la plupart des devs web n'ont pas. Je suis dev PHP/JS, et ça se sent. Ce qui voyage quand même : les huit patterns de lecture, le Reservation Pattern, la frontière entre événements internes et Integration Events, la structure de test Given-When-Then. Lis la première moitié, pioche dans les patterns, et ne te sens pas coupable pour le reste.
Le petit, quand tu rejoins une équipe
The Little Eventmodeling Book (Dilger, 2025, 72 pages, 6/10) répond à dix-sept questions pour comprendre le langage de l'Event Modeling avant d'entrer dans un atelier. L'Information Completeness Check justifie la lecture à lui seul : tu dessines un read model, quelqu'un demande « mais d'où vient ce champ ? », et personne ne sait. En faire une contrainte qui bloque l'implémentation est une idée simple et puissante.
Deux réserves. Environ 15 % du contenu est commercial. Et l'Event Modeling est une méthode visuelle : en PDF, tu perds la moitié de la substance. Il suffit pour suivre une conversation d'équipe, pas pour pratiquer seul.
Kleppmann, sous tout ça
Ce n'est pas un livre d'Event Sourcing, mais Designing Data-Intensive Applications (2017, 8,4/10) explique pourquoi ces patterns existent : réplication, cohérence, pannes, journal. C'est le meilleur livre d'ingénierie backend que j'ai lu, et l'opinion est banale parce qu'elle est juste. Un dev web passera un excellent moment dans les chapitres 1 à 8. Le batch processing version Hadoop se lit aujourd'hui comme de l'histoire ancienne, tu peux le survoler.
L'ordre que je suivrais
| # | Livre | Pages | Note | Pour quoi faire |
|---|---|---|---|---|
| 1 | Learning DDD | 340 | 8,6 | Le cadre, avant les patterns |
| 2 | Exploring CQRS and ES | 200 | 8,2 | Voir le coût réel, comprendre les Sagas |
| 3 | Understanding Eventsourcing | 650 | 7,5 | La première moitié, puis les patterns |
| 4 | Little Eventmodeling Book | 72 | 6 | Suivre un atelier d'équipe |
| au besoin | Evans + Reference | 560 + 59 | 7 / 6,4 | Le vocabulaire, chapitre par chapitre |
| en fond | Kleppmann | ~600 | 8,4 | Le terrain sous les patterns |
Pour passer de la lecture à la pratique en Go, mes articles suivent ce parcours : le guide pratique Event Sourcing et CQRS, puis PostgreSQL comme event store et l'idempotence.
Conclusion
Les livres sur l'Event Sourcing vendent presque tous les bénéfices. Un seul de ces six montre la facture, et c'est le plus vieux, le moins glamour, celui qui parle d'Azure en 2012. La note ne suit pas la date : le meilleur point de départ n'est pas le plus récent, et le plus récent n'est même pas le plus utile.
Si lire six livres dans un ordre précis te paraît lourd, c'est que chacun parle à un niveau différent du métier. J'ai recousu la moelle de dizaines de livres tech dans un seul fil, des bits et du Big O jusqu'à l'ère de l'IA : c'est Le grand livre du développeur. Le DDD et l'architecture y ont leur place, au niveau où ils deviennent utiles.
📚 Autres comparatifs. Livres sur le code propre et le refactoring : dans quel ordre les lire et Livres DevOps et management d'équipe tech : dans quel ordre les lire.