Les microservices axés sur les événements représentent un changement fondamental dans la façon dont les systèmes logiciels modernes sont conçus pour l'échelle, la résilience et l'alignement des affaires. Combinés à la conception axée sur le domaine (DDD), ces architectures vont au-delà du découplage technique pour créer des systèmes qui reflètent le langage et les contraintes du domaine opérationnel réel.

Comprendre les microservices pilotés par des événements

Dans une architecture traditionnelle axée sur les requêtes, les services communiquent synchronement par l'intermédiaire d'appels HTTP ou RPC. Cela crée un couplage temporel serré – l'appelant doit attendre que l'appelant réponde. Les microservices axés sur les événements inversent ce modèle : les services publient des événements (messages représentant quelque chose qui est arrivé) à un courtier de messages, et d'autres services consomment ces événements de manière asynchrone.

Les composantes essentielles d'une architecture de microservice axée sur l'événement comprennent :

  • Producers: Services qui détectent et émettent des événements (p. ex., «Ordonnance Placée»)
  • Consommateurs d'événements[: Services qui s'abonnent aux événements et réagissent en conséquence
  • Courtier de messagerie[: Middleware comme Apache Kafka, RabbitMQ, ou Amazon EventBridge qui stocke et itinéraires événements
  • Registre des événements[: un magasin central pour les contrats d'événements, permettant la version et l'évolution

Ce modèle améliore l'évolutivité car chaque service peut être étendu indépendamment en fonction de sa propre charge. La résilience s'améliore parce qu'une défaillance du consommateur ne bloque pas le producteur – les événements persistent et peuvent être retransformés plus tard. De plus, les systèmes axés sur les événements soutiennent naturellement une cohérence éventuelle, qui est souvent plus appropriée que les transactions distribuées pour les systèmes à grande échelle.

Principes fondamentaux de la conception axée sur le domaine

Eric Evans et la communauté DDD ont affiné leur conception axée sur le domaine au fil des décennies. L'objectif est de créer des logiciels qui modélisent fidèlement le domaine d'activité plutôt que de s'enchevêtrer dans les problèmes d'infrastructure.

Contextes bombés

Un contexte délimité est une limite logique à l'intérieur de laquelle un modèle de domaine particulier s'applique. Par exemple, le concept de «client» peut différer entre le contexte de vente (où un client est un leader avec des informations de contact) et le contexte de livraison (où un client est une adresse et des préférences de livraison). Chaque contexte délimité a sa propre langue omniprésente.

Entités et objets de valeur

Les entités sont des objets avec une identité unique qui persiste au fil du temps (par exemple, un ordre avec un identifiant d'ordre).Les objets de valeur sont des objets immuables qui décrivent des aspects du domaine sans identité dédiée (par exemple, Adresse, Argent).Dans les microservices axés sur les événements, les événements eux-mêmes sont souvent des objets de valeur – ils représentent un moment dans le temps et devraient être immuables.

Agrégats

Un agrégat est un groupe d'objets de domaine qui peuvent être traités comme une unité unique. Une limite de transaction assure la cohérence au sein de l'agrégat. Dans une architecture axée sur les événements, les événements sont publiés lorsqu'un état de changement d'agrégat. Par exemple, lorsqu'un agrégats de transitions de «en attente» à «confirmé», le système publie un agrégats de transition.

Événements de domaine

Ce sont les pierres angulaires des systèmes axés sur les événements. un événement de domaine capture quelque chose qui s'est passé dans le domaine que les experts du domaine s'intéressent. Les événements sont nommés dans le passé (par exemple, InvoicePaid[, InventoryReserved[) et portent les données nécessaires pour que les consommateurs réagissent.

Conception de Microservices avec DDD

L'application de la DDD au microservice ne consiste pas seulement à diviser un monolithe en services plus petits. Elle nécessite une décomposition méthodique du domaine d'affaires en contextes délimités, chacun de ces éléments étant un candidat pour un microservice. Le processus comporte trois phases principales : la conception stratégique, la conception tactique et la modélisation d'événements.

Conception stratégique : découverte de contextes solides

Commencez par une session Domain Storytelling[ ou Event Storming[. Rassemblez experts et développeurs de domaines pour cartographier le flux des activités commerciales. Lorsque vous identifiez des événements et des commandes, les groupez dans des contextes. Pour un système de commerce électronique, les contextes limités typiques peuvent inclure:

  • Gestion de la commande: chariot de poignées, commande, machine d'état de commande
  • Inventory: voie les niveaux de stock, les réservations, le restockage
  • Facturation : factures, paiements, remboursements
  • Fulfillment: expédition, suivi, livraison
  • Gestion des clients[: profils, préférences, authentification

Chacun de ces contextes deviendra un microservice. La Conttext Map permet de visualiser les relations entre les contextes, en particulier les contextes en amont (événements de production) et en aval (événements de consommation).

Conception tactique : modélisation dans un contexte encombré

Dans chaque contexte délimité, construisez un modèle de domaine riche en utilisant des entités, des objets de valeur, des agrégats et des événements de domaine. Par exemple, dans le contexte de la gestion des commandes, vous pouvez définir :

  • Commande (racine agrégée): contient des articles, état, adresse d'expédition
  • Commandement (entité): références un produit, quantité, prix
  • Adresse d'expédition (objet de valeur): rue, ville, zip
  • OrdrePlacé (événement principal): soulevé lors de la soumission de l'ordonnance
  • OrdonnanceScipped (événement principal): soulevé lors de la transition de commande à expédier

La racine agrégée garantit que tous les invariants (p. ex., calcul total, transitions de statut) sont appliqués avant la publication d'un événement.Cela s'harmonise avec le Agrémenté et empêche les fuites d'états incompatibles avec les consommateurs.

Modélisation des événements : définition des événements et chorégraphie

Une fois les contextes délimités définis, modélisez les événements qui se produisent entre eux. Utilisez une technique collaborative comme Modélisation des événements[ (créée par Adam Dymitruk). Commencez par une chronologie : lisez les événements dans l'ordre chronologique comme ils se produisent dans un voyage utilisateur. Pour chaque événement, décidez quel contexte le produit et quels contextes le consomment. Pour un flux de placement d'ordre, la chorégraphie pourrait ressembler à :

  1. Gestion des commandes → publie OrdrePlacé
  2. Inventory ← consomme OrdonnancePlacée[, réserve des stocks, puis publie InventoryRéservé (ou RéservationÉchec)
  3. Facturation ← consomme InventoryReserved[, traite le paiement, publie PaiementSuccédé ou PaiementÉchec
  4. Gestion des commandes ← consomme PaiementSuccédé, change le statut de l'ordre à "confirmé", publie OrdonnanceConfirmé
  5. Fulfillment ← consomme OrdreConfirmé, déclenche l'expédition, publie Scipé

Cette chorégraphie élimine la nécessité d'un orchestre central. Chaque service réagit aux événements et peut produire de nouveaux événements. Le système dans son ensemble atteint une cohérence éventuelle. Pour gérer les échecs, les services doivent être idéoptents et capables de retraiter les événements.

Avantages de la combinaison de l'architecture d'événements et de la DDD

La synergie entre l'architecture axée sur les événements et la DDD offre plusieurs avantages mesurables par rapport aux conceptions traditionnelles de services :

Couplage de la marge

Les services communiquent exclusivement par des événements, et non par des appels d'API directs. Un événement est un message d'incendie et d'oubli : le producteur ne s'attend pas à une réponse synchrone. Cela élimine le couplage d'exécution. Un consommateur peut être ajouté ou retiré sans impact sur le producteur.

Échelle

Un pic dans les placements en ordre ne force pas le service d'inventaire à l'échelle au même degré; les événements sont tamponnés dans le courtier. De plus, vous pouvez ajouter de nouveaux consommateurs d'événements (p. ex., un moteur de recommandation qui écoute OrdonnancePlaced) sans modifier les services existants.

Résilience

Si le service de facturation est en panne, la Direction des commandes publie toujours des événements qui persistent. Lorsque la facturation se rétablit, elle rejoue l'arriéré. C'est beaucoup plus robuste que les chaînes synchrones où une cascade de temps à travers le système entier. En DDD, la limite globale assure que chaque service peut rester cohérent sans attendre les services en aval.

Alignement du domaine

L'avantage le plus fort peut-être : l'architecture reflète l'entreprise. Les événements sont nommés dans le langage des experts du domaine. Cela rend le système transparent aux intervenants et plus facile à évoluer au fur et à mesure que l'entreprise change.

Défis et meilleures pratiques

Bien que la combinaison des microservices axés sur les événements et de la DDD soit puissante, elle introduit de nouvelles complexités qui exigent des pratiques techniques disciplinées.

Gestion de la cohérence événementielle

Lorsque les services sont couplés de façon lâche par des événements, le système est finalement cohérent. Un utilisateur peut voir un statut de « paiement en attente » brièvement avant que l'événement PaiementSuccédé se propage. Ceci est acceptable pour de nombreux domaines, mais vous devez concevoir l'expérience utilisateur en conséquence. Utilisez Saga patterns (chorégraphie ou orchestration) pour gérer des transactions en plusieurs étapes. Par exemple, si le service Inventory ne se réserve pas, le service de gestion des commandes doit réagir à un événement de compensation et annuler l'ordre.

Version des événements et schéma Evolution

Les événements sont des enregistrements immuables du passé, mais leurs schémas doivent évoluer. Adoptez un Registre de schéma d'événement (comme le registre de schéma de confluent ou une solution personnalisée) pour faire appliquer les vérifications de compatibilité. Utilisez un format de sérialisation qui supporte l'évolution du schéma, comme Avro, Protobuf ou JSON Schema avec la version. Les meilleures pratiques comprennent:

  • Toujours ajouter de nouveaux champs en option avec des par défaut.
  • Ne pas supprimer les champs sans une période de déprécation.
  • Événements de version au niveau du schéma (p. ex., OrdonnancePlacedV2).
  • Tenir les consommateurs tolérants aux anciennes versions (compatibilité préalable).

Avis d'approvisionnement en événements contre avis d'événement

De nombreuses implémentations utilisent event notifications—messages qui informent les autres services d'un changement sans stocker l'historique complet de l'événement. En revanche, event sourcing persiste chaque changement d'état comme un journal de l'appendice seulement et dérive l'état actuel de rejouer des événements. Event sourcing paires naturellement avec les agrégats DDD mais introduit la complexité dans la requête et la gestion des schémas. Utilisez le sourcing d'événements seulement lorsque vous avez besoin de pistes d'audit complètes, de requêtes temporelles ou de soutien pour la reconstruction d'état complexe.

Idempotency et traitement exactement une fois

Les systèmes distribués produisent souvent des événements au moins une fois. Concevez vos consommateurs pour qu'ils soient idéopontes : traiter le même événement deux fois doit produire le même résultat. Une approche commune est de déduquer par ID d'événement. Dans DDD, l'ID agrégé combiné au numéro de séquence d'événement peut servir de clé de duplication.

Surveillance et observation

Mettre en œuvre distributed tracing[ (p. ex. OpenTelemetry) avec un identifiant de corrélation qui voyage à travers chaque événement. Enregistrer tous les événements d'édition et de consommation d'événements avec des horodatages. Utiliser des files d'attentes de lettres mortes[ pour les événements qui échouent à traiter plusieurs fois. Instrumenter votre courtier de messages avec des mesures comme le décalage d'événement (combien derrière un consommateur) et traiter la la latence.

Étapes pratiques pour commencer

  1. Run an Event Storming workshop[ avec des experts de domaine pour identifier tous les événements de domaine, commandes et contextes délimités.
  2. Définir la carte du contexte. Déterminer quels contextes seront des microservices et dessiner les relations amont/aval.
  3. Choisissez votre courtier d'événement (Kafka pour un débit élevé, RabbitMQ pour un routage plus simple, ou cloud-native comme AWS EventBridge).
  4. Dessiner des schémas d'événements[ en collaboration avec un registre. Commencez par quelques événements de base.
  5. Mise en œuvre d'un service suivant les modèles tactiques DDD. Publier son premier événement de domaine.
  6. Construire un consommateur dans un autre service. Tester le débit asynchrone de bout en bout.
  7. Élargir graduellement. Ajouter plus d'événements, plus de consommateurs et mettre en œuvre des sagas pour les flux critiques.

Exemple du monde réel : Exécution de la commande de commerce électronique

Le service de gestion des commandes reçoit une commande pour passer une commande.Le service de gestion des commandes est un agrégat avec éléments et total.Après validation des invariants (éléments en stock? paiement suffisant?], il publie OrderPlacé[ avec données: ordreId, clientId, items, totalMontant, timetam. Inventoryle service de gestion des commandesreserve le stock en décréant l'agrégat et publie StockReserved.Si le stock est insuffisant, il publie StockReservationFLT]etlift[FLT][FLT][FLT][FLT]]][Filedite[File

Ressources extérieures

Pour approfondir votre compréhension de ces concepts, explorez les sources faisant autorité suivantes :

Conclusion

La conception de microservices axés sur les événements et les principes de conception axés sur le domaine est une approche éprouvée des systèmes de construction techniquement robustes et orientés vers les entreprises. La combinaison de contextes limités, d'agrégats, d'événements de domaine et de chorégraphie asynchrone donne un couplage lâche, une évolutivité indépendante et une résilience. Bien que les défis comme la cohérence et la version des événements nécessitent une planification minutieuse, le système de paiement peut évoluer avec l'entreprise sans accumuler de dettes techniques.