Pourquoi l'event sourcing pour une plateforme multi-tenant

Quand j'ai commencé à reconstruire Symplicia, la question de la persistance s'est posée très vite. Une architecture CRUD classique aurait suffi pour un MVP, mais elle rend difficile la traçabilité des changements d'état sur un bien locatif — qui a modifié quoi, et quand.

L'event sourcing avec EventStoreDB résout ce problème à la racine : chaque changement devient un événement immuable. On peut reconstruire l'état d'une annonce à n'importe quel instant, et ça simplifie énormément l'audit et le support client.

class LeaseCreated {
  constructor(tenantId, propertyId, startDate) {
    this.tenantId = tenantId;
    this.propertyId = propertyId;
    this.startDate = startDate;
  }
}

Le vrai coût, c'est la complexité initiale — il faut penser en événements dès la modélisation du domaine, et ça change la façon d'écrire les tests. J'y reviendrai dans un prochain article sur la stratégie de test à cinq niveaux que j'utilise sur ce projet.

Pour aller plus loin sur le sujet, la documentation d'EventStoreDB (https://www.eventstore.com/) reste la meilleure ressource pour comprendre les patterns d'implémentation.