Dénormalisation et event sourcing

Prérequis : cours 4.2 (CQRS/projections) et 6.1.

Pourquoi

La normalisation protège l'écriture ; la lecture veut du plat et du vite. Pousser la logique au bout donne deux extrêmes utiles : dénormaliser assumé, et event sourcing (le journal comme source de vérité).

Concepts

• Dénormalisation : dupliquer pour lire vite (nom du client dans la ligne de commande). Prix : double écriture + risque de divergence → synchronisé par événements/projections, jamais à la main.
• Event sourcing : on ne stocke pas l'état mais les événements (FundsAdded, OrderPlaced) ; l'état se rejoue. Audit parfait (« que s'est-il passé ? » = relire le journal), voyage temporel, projections multiples.
• Snapshots : photo périodique pour ne pas rejouer 10 ans à chaque lecture. Sans snapshots, la lecture ralentit avec l'âge.
• Quand NON : CRUD simple, équipe petite, requêtes ad hoc fréquentes (le journal se query mal). Event sourcing = investissement : à réserver aux domaines à audit fort ou règles temporelles (compta, paris, inventaire).

Exemple : compte bancaire

Événements : Opened → Deposited(100) → Withdrawn(30) → état = 70 (rejoué)
Projection : balance lue en 1 SELECT ; audit : relire les 3 événements

Cas réel

Facturation refacturée « comme il y a 6 mois » pour un litige : avec event sourcing, replay à date + règles d'alors = facture identique prouvée. Avec état écrasé : impossible, parole contre parole.

Pièges

• Schémas d'événements qui changent sans version/migration (upcasting) : le replay casse sur l'historique.
• Données personnelles dans un journal immuable (RGPD !) : chiffrement + clés jetables, ou ne pas y mettre de PII. Le « droit à l'oubli » et l'append-only sont ennemis.
• Projections multiples non reconstruites : prévoir le replay dès le jour 1 (cf. 4.2).

À retenir

Dénormaliser pour lire (sync par événements), sourcing pour auditer (snapshots + versions), RGPD pensé avant.