Event Sourcing vs CRUD : Utilisez-le pour l'audit, pas pour l'esthétique

Le sourcing d'événements est survendu de deux manières différentes.

Un groupe le traite comme la seule manière sérieuse de modéliser des systèmes d'affaires. Un autre groupe le rejette comme du cosplay architectural. Les deux ont tort.

Le sourcing d'événements est justifié lorsque l'historique des changements fait partie de la valeur commerciale, et n'est pas seulement un détail d'implémentation.

Si tout ce dont vous avez besoin est un CMS de blog ou un panneau d'administration simple, le CRUD est généralement la bonne abstraction. Si vous construisez un livre de comptes, un flux de travail lourd en audit, ou un domaine où la reconstruction des décisions est importante, le sourcing d'événements devient une option sérieuse.

La Différence Essentielle

Dans un modèle CRUD, la ligne actuelle est la source de vérité.

Dans un modèle basé sur le sourcing d'événements, la source de vérité est un flux d'événements de domaine en écriture uniquement, et l'état actuel est dérivé de ces événements.

Cette différence peut sembler minime sur le papier. Elle change beaucoup en pratique.

Une mise à jour CRUD :

UPDATE subscriptions
SET plan = 'pro', updated_at = now()
WHERE id = 'sub_123';

Une écriture basée sur le sourcing d'événements :

{
  "type": "SubscriptionUpgraded",
  "subscriptionId": "sub_123",
  "previousPlan": "starter",
  "newPlan": "pro",
  "occurredAt": "2024-03-22T05:23:50Z"
}

La première déclaration vous dit ce qui est vrai maintenant.
La seconde vous dit ce qui s'est passé.

Cette distinction est importante lorsque les auditeurs, le personnel de soutien ou les systèmes en aval ont besoin de la séquence, et pas seulement du résultat.

Pourquoi les Équipes y Recourent

Le sourcing d'événements justifie sa complexité lorsque vous avez besoin d'une combinaison de :

un solide historique d'audit
de la relecture
des requêtes temporelles telles que "qu'est-ce que nous croyions hier ?"
des événements de domaine explicites pour les consommateurs en aval

Il est particulièrement attrayant lorsque l'historique des changements est un concept commercial de première classe plutôt qu'une réflexion après coup.

Pourquoi les Équipes le Regrettent

Le coût est réel :

vous avez besoin de projections pour des lectures efficaces
l'évolution du schéma devient une préoccupation continue
la cohérence éventuelle fait partie de l'expérience produit
le débogage opérationnel devient plus difficile

Un système CRUD peut souvent répondre à une question de soutien avec une seule requête.
Un système basé sur le sourcing d'événements peut nécessiter la compréhension du flux, de la projection et si la projection est à jour.

C'est pourquoi le sourcing d'événements devrait être choisi pour des raisons commerciales, et non parce qu'il semble plus élégant.

Le Modèle de Lecture n'est pas Optionnel

Un journal d'événements pur n'est pas un bon magasin de lecture généraliste.

Dans les systèmes réels, le sourcing d'événements se retrouve généralement associé à des projections ou à des modèles de lecture de type CQRS :

type SubscriptionProjection = {
  id: string;
  currentPlan: string;
  status: "active" | "canceled";
  renewedAt: string | null;
};

async function handle(event: DomainEvent) {
  switch (event.type) {
    case "SubscriptionUpgraded":
      await db.query(
        `UPDATE subscription_projection
         SET current_plan = $2
         WHERE id = $1`,
        [event.subscriptionId, event.newPlan],
      );
      break;
  }
}

Le flux d'événements préserve l'historique.
La projection rend le système utilisable.

Les Parties Difficiles que Personne ne Saute

Si vous adoptez le sourcing d'événements, planifiez ces éléments dès le premier jour :

Versionnage des événements

Votre compréhension du domaine changera. Les anciens événements doivent encore être lisibles.

Consommateurs idempotents

Les gestionnaires doivent tolérer la livraison ou la relecture en double.

Reconstructions de projection

Vous avez besoin d'un moyen sûr de reconstruire les modèles de lecture à partir du flux source.

Visibilité opérationnelle

Vous devez savoir si une projection est à jour, en retard, ou brisée.

Rien de tout cela n'est théorique. C'est la surface opérationnelle quotidienne du système.

Une Règle Décisionnelle Utile

Utilisez CRUD lorsque :

l'état actuel est ce qui préoccupe principalement l'entreprise
l'audit peut être géré par une journalisation conventionnelle
le domaine est simple et riche en requêtes

Envisagez le sourcing d'événements lorsque :

la séquence de changement a de la valeur en soi
la correction et la relecture sont des flux de travail essentiels
plusieurs systèmes en aval dépendent des événements de domaine

Ce n'est pas une question de maturité architecturale. C'est une question d'adéquation.

Event Sourcing vs CRUD : Utilisez-le pour l'audit, pas pour l'esthétique_