jeudi 16 octobre 2014

Event sourcing

Event sourcing

Une introduction de l'Event Sourcing par une comparaison avec les RDBMs. En RDBMs les objets sont mappés sur les tables. Tout changement, même partiel, d'état de l'objet en mémoire entraîne une mise à jour complète de la table en base. La table ne contient donc que le dernier état de l'objet. Avec l'approche Event Sourcing pas besoin de faire du mapping Object-Relanionnal, ce sont les événements (Event) - Création, Suppression et Modification - qu'on stocke dans la base. Le gain en performance peut être assez considérable. On maintient l'historique des différents états intermédiaires de la table de sorte à pouvoir construire son état courant ou retrouver différents états avec des Revert et des Rollback comme dans un SGV.
On peut lire sur le blog de Martin Fowler :
The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself.
Exemple d'un compte bancaire : source http://ookami86.github.io/event-sourcing-in-practice/

En RDBM on aura un seul objet pour la table
Account (accountNumber, owner, amount)
En Event Sourcing on créera un objet Event pour chaque événement sur l'objet
AcountCreated(accountNumber, owner) pour la création de compte DepositedPerormed(accountNumber, amount) pour le crédit WithdrawPerormed(accountNumber, amount) pour le débit
Restauration : Retrouver l'état courant à partir des Events
AcountCreated(accountNumber, amount)
.applyTo(EmptyAccount) => Account (accountNumber, owner, 0)
DepositedPerormed(accountNumber, 100)
.applyTo(Account (accountNumber, owner, 0)) => Account (accountNumber, owner, 100)