Event sourcing
Un patron où l'on stocke tous les changements sous forme d'une suite immuable d'événements plutôt que de ne sauvegarder que l'état courant. L'état actuel se déduit en rejouant les événements. On obtient l'historique complet, l'audit et la possibilité de « voyager dans le temps ».
L'idée : au lieu de UPDATE account SET balance = 100, on enregistre des événements (« DepositedMoney 50 », « Withdrew 20 ») — le solde est la somme des événements. Le gain : un historique d'audit complet offert d'office, la faculté de reconstituer l'état à n'importe quel instant, et celle de construire après coup de nouvelles vues en rejouant le journal. Souvent associé à CQRS (modèles de lecture et d'écriture séparés) et aux « projections » (vues matérialisées du flux d'événements).
Le revers : c'est complexe — évolution du schéma des vieux événements, snapshots nécessaires pour la performance, cohérence à terme entre modèles d'écriture et de lecture. Cas d'usage : la finance, l'e-commerce, tous les domaines où le « pourquoi » et l'historique sont centraux (DDD). Outils : EventStoreDB, Kafka comme journal. Cousin des journaux en ajout seul et des bases ledger.