Technical Tutorials

Dans le domaine de la conception de systèmes modernes, le paradigme traditionnel CRUD (Create, Read, Update, Delete) montre souvent ses limites face à des domaines métier complexes, à une conformité réglementaire stricte ou à des exigences de données à grande échelle. C'est là que l'Event Sourcing brille. En traitant l'état de l'application comme une série d'événements immuables, l'Event Sourcing offre une alternative robuste qui fournit des journaux d'audit complets, des capacités de requêtage temporel et une évolutivité améliorée.

Qu'est-ce que l'Event Sourcing ?

Au cœur de l'Event Sourcing se trouve un patron architectural où les changements de l'état d'une application sont stockés sous forme d'une séquence d'événements. Au lieu de ne stocker que l'état actuel des données (comme l'adresse d'un client), vous stockez chaque événement qui a modifié cet état (par exemple, « Adresse mise à jour », « Adresse créée »). Pour reconstruire l'état actuel, le système rejoue simplement ces événements depuis le début.

Cette approche contraste fortement avec les couches de persistance traditionnelles. Dans une base de données relationnelle standard, la mise à jour du profil d'un utilisateur pourrait ressembler à une instruction SQL UPDATE qui écrase les données précédentes. Dans l'Event Sourcing, cette même action génère un nouvel événement « UserProfileUpdated », laissant le record historique intact.

Principaux avantages pour les systèmes d'entreprise

Adopter l'Event Sourcing n'est pas seulement un choix technique ; c'est un facilitateur commercial. Voici les principaux avantages :

Journal d'audit complet : Puisque chaque changement est un événement immuable, vous disposez d'un journal d'audit intégré. Vous pouvez retracer exactement ce qui s'est produit, quand cela s'est produit et qui en est la cause.
Requêtage temporel : Vous pouvez reconstruire l'état de votre domaine à n'importe quel moment. Cela est inestimable pour le débogage, l'analyse forensique et la génération de rapports historiques.
Découplage : Les événements peuvent déclencher d'autres processus. Un événement « OrderPlaced » peut simultanément mettre à jour l'inventaire, notifier l'expédition et envoyer un e-mail de confirmation sans couplage étroit.

Mise en œuvre de l'Event Sourcing : Un exemple pratique

Examinons comment vous pourriez structurer un Event Store en Java. Bien que vous utilisiez généralement une base de données de stockage d'événements dédiée (comme EventStoreDB ou Apache Kafka), le modèle conceptuel reste le même : un référentiel d'événements.


public class OrderAggregate {
    private List events = new ArrayList<>();
    private BigDecimal totalAmount;
    private String status;

    // Rejouer les événements pour reconstruire l'état
    public void replay(List historicalEvents) {
        historicalEvents.forEach(this::apply);
    }

    // Appliquer un nouvel événement à l'état actuel
    public void apply(OrderEvent event) {
        if (event instanceof OrderCreatedEvent) {
            this.totalAmount = ((OrderCreatedEvent) event).getAmount();
            this.status = "CREATED";
        } else if (event instanceof OrderCancelledEvent) {
            this.status = "CANCELLED";
        }
        // Ajouter au tampon local pour être persisté
        events.add(event);
    }

    // Sauvegarder les événements en attente dans le stockage d'événements
    public void persist() {
        eventStore.save(events);
        events.clear();
    }
}

Dans cet exemple, l'OrderAggregate ne stocke pas son état uniquement dans des variables persistantes. Au lieu de cela, il maintient une liste d'événements non validés. Une fois la transaction terminée, ces événements sont sauvegardés dans le stockage d'événements. Pour charger l'agrégat plus tard, le système récupère tous les événements associés à l'ID de commande et les rejoue en utilisant la méthode apply.

Défis et considérations

Bien que puissant, l'Event Sourcing introduit de la complexité. Vous devez gérer soigneusement la migration des événements (évolution du schéma), car les événements sont immuables mais votre logique de traitement peut changer. De plus, les modèles de lecture nécessitent souvent un stockage séparé (comme Elasticsearch ou une base de données SQL) pour servir les requêtes efficacement, car rejouer des millions d'événements pour une simple opération de lecture est coûteux en calcul.

Conclusion

L'Event Sourcing n'est pas une solution miracle, mais c'est un outil transformateur pour des cas d'utilisation spécifiques. Si votre domaine repose fortement sur une logique métier complexe, nécessite une auditage rigoureux ou doit prendre en charge l'analyse de données historiques, l'Event Sourcing fournit la fondation architecturale pour construire des systèmes résilients, évolutifs et transparents. En embrassant l'« histoire » de vos données plutôt que simplement leur instantané actuel, vous débloquez de nouvelles possibilités pour la conception de logiciels d'entreprise.