Architecture
Diagramme d'architecture event sourcing où tous les changements d'état sont stockés comme une séquence immuable d'événements de domaine, avec des projections de lecture construites à partir du flux d'événements et une optimisation par snapshots pour un chargement rapide des agrégats. Ce modèle montre comment l'event sourcing élimine la perte de données en préservant l'historique complet de chaque transition d'état. Critique pour les systèmes nécessitant des pistes d'audit complètes, des requêtes temporelles et des capacités de rejeu d'événements.
Code FlowZap complet
Command { # Command Side
n1: circle label:"User Command"
n2: rectangle label:"Validate Command"
n3: rectangle label:"Load Aggregate"
n4: rectangle label:"Apply Business Rules"
n5: rectangle label:"Emit Domain Events"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Valid"]
n3.handle(right) -> n4.handle(left) [label="Current State"]
n4.handle(right) -> n5.handle(left) [label="State Change"]
n5.handle(bottom) -> EventStore.n6.handle(top) [label="Append"]
}
EventStore { # Event Store
n6: rectangle label:"Append Event to Stream"
n7: rectangle label:"Assign Sequence Number"
n8: rectangle label:"Persist Immutable Event"
n9: rectangle label:"Publish to Projections"
n10: rectangle label:"Snapshot Manager"
n6.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left) [label="Write-Ahead Log"]
n8.handle(right) -> n9.handle(left) [label="Notify"]
n9.handle(bottom) -> Projections.n11.handle(top) [label="Event Stream"]
n10.handle(top) -> Command.n3.handle(bottom) [label="Fast Load"]
}
Projections { # Read Projections
n11: rectangle label:"Event Handler"
n12: rectangle label:"Build Read Model"
n13: rectangle label:"Update Materialized View"
n14: rectangle label:"Serve Query"
n15: circle label:"Query Response"
n11.handle(right) -> n12.handle(left) [label="Transform"]
n12.handle(right) -> n13.handle(left) [label="Upsert"]
n13.handle(right) -> n14.handle(left) [label="Ready"]
n14.handle(right) -> n15.handle(left)
}
Replay { # Event Replay
n16: rectangle label:"Replay from Offset"
n17: rectangle label:"Rebuild Projection"
n18: rectangle label:"Verify Consistency"
n16.handle(right) -> n17.handle(left) [label="Historical Events"]
n17.handle(right) -> n18.handle(left) [label="Rebuilt"]
n18.handle(top) -> Projections.n13.handle(bottom) [label="Replace View"]
}
Pourquoi ce workflow ?
Traditional CRUD systems overwrite state on every update, losing the history of how the current state was reached. Event sourcing preserves every state change as an immutable event, enabling full audit trails, temporal queries, debugging by replaying events, and the ability to rebuild read models from scratch.
Comment ça fonctionne
- Step 1: A user command is validated against the current aggregate state.
- Step 2: The aggregate applies business rules and emits one or more domain events.
- Step 3: Events are appended to the event store with a sequence number (never updated or deleted).
- Step 4: Read projections consume the event stream and build materialized views.
- Step 5: Snapshots are periodically created to speed up aggregate loading.
- Step 6: Event replay can rebuild any projection from any point in time.
Alternatives
Traditional CRUD with audit tables captures changes but cannot rebuild state. Change Data Capture provides similar benefits without changing application code. This template shows the full event sourcing architecture with projections and replay.
Key Facts
| Template Name | Architecture événementielle Event Sourcing |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture CQRS combinant des API de commande et de requête séparées avec un bus d'événements pour la synchronisation asynchrone du modèle de lecture, incluant des projecteurs qui construisent des vues dénormalisées à partir des événements de domaine. Ce modèle démontre la pile complète CQRS+ES où les écritures passent par la validation du domaine et les lectures sont servies depuis des vues matérialisées optimisées. Idéal pour les systèmes à haut débit où les charges de lecture et d'écriture ont des exigences de mise à l'échelle fondamentalement différentes.
Architecture
Diagramme d'architecture DDD des contextes bornés avec les contextes Commande, Client, Expédition et Facturation connectés via une couche anti-corruption, un noyau partagé et une carte de contextes définissant les relations d'intégration. Ce modèle visualise les patterns stratégiques DDD pour décomposer des domaines complexes en contextes bornés autonomes qui communiquent par des événements d'intégration bien définis. Critique pour les architectes appliquant le Domain-Driven Design aux systèmes d'entreprise à grande échelle.
patterns
Modèle de sourcing d'événements avec capture d'événements, persistance en magasin d'événements, reconstruction d'agrégats, optimisation par instantanés et requêtes d'état temporel.
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.