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.
Code FlowZap complet
WriteAPI { # Write API (Command)
n1: circle label:"POST/PUT Request"
n2: rectangle label:"Command Handler"
n3: rectangle label:"Validate Business Rules"
n4: rectangle label:"Persist to Write DB"
n5: rectangle label:"Publish Domain Event"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left)
n3.handle(right) -> n4.handle(left) [label="Valid"]
n4.handle(right) -> n5.handle(left) [label="Committed"]
n5.handle(bottom) -> EventBus.n6.handle(top) [label="OrderPlaced"]
}
EventBus { # Event Bus (Kafka)
n6: rectangle label:"Receive Domain Event"
n7: rectangle label:"Route to Topic"
n8: rectangle label:"Guarantee Delivery"
n9: rectangle label:"Fan-Out to Consumers"
n6.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left) [label="At-Least-Once"]
n8.handle(right) -> n9.handle(left)
n9.handle(bottom) -> ReadSide.n10.handle(top) [label="Consume"]
n9.handle(bottom) -> Projector.n14.handle(top) [label="Consume"]
}
ReadSide { # Read API (Query)
n10: rectangle label:"Query Handler"
n11: rectangle label:"Read from Read DB"
n12: rectangle label:"Transform to DTO"
n13: circle label:"GET Response"
n10.handle(right) -> n11.handle(left)
n11.handle(right) -> n12.handle(left) [label="Denormalized"]
n12.handle(right) -> n13.handle(left)
}
Projector { # Read Model Projector
n14: rectangle label:"Event Handler"
n15: rectangle label:"Update Read Model"
n16: rectangle label:"Rebuild Materialized View"
n17: diamond label:"Consistency Check"
n18: rectangle label:"Mark Projection Current"
n14.handle(right) -> n15.handle(left) [label="Transform"]
n15.handle(right) -> n16.handle(left) [label="Upsert"]
n16.handle(right) -> n17.handle(left)
n17.handle(right) -> n18.handle(left) [label="Consistent"]
n18.handle(top) -> ReadSide.n11.handle(bottom) [label="Updated"]
}
Pourquoi ce workflow ?
Systems with high read-to-write ratios suffer when the same data model serves both commands and queries. CQRS with an event store separates the write path (optimized for consistency) from the read path (optimized for speed), allowing each to scale independently while domain events keep them synchronized.
Comment ça fonctionne
- Step 1: Write requests go through a command handler that validates business rules.
- Step 2: Valid commands are persisted to the write database and a domain event is published.
- Step 3: The event bus guarantees at-least-once delivery to all subscribed projectors.
- Step 4: Projectors transform domain events into denormalized read models optimized for specific queries.
- Step 5: The read API serves queries directly from the optimized read database.
- Step 6: Consistency checks monitor lag between write and read models.
Alternatives
A single database with read replicas is simpler but limits query optimization. GraphQL can reduce over-fetching without full CQRS. This template shows the complete CQRS+ES architecture for teams that need independent read/write scaling.
Key Facts
| Template Name | Architecture CQRS événementielle avec Event Store |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture CQRS de vues matérialisées avec plusieurs projecteurs construisant des modèles de lecture spécifiques : résumés de commandes, tableaux de bord clients, cubes analytiques et index de recherche, tous alimentés par un flux d'événements unique. Ce modèle montre comment créer plusieurs vues de requête optimisées à partir des mêmes événements d'écriture, chacune adaptée à un cas d'usage spécifique avec une latence de lecture inférieure à la milliseconde. Parfait pour les systèmes nécessitant des patterns de requête diversifiés à partir d'une source de données unique.
patterns
Patron CQRS (Command Query Responsibility Segregation) avec chemins de commande et de requête séparés, publication d'événements de domaine, synchronisation du modèle de lecture et transformation DTO.
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.
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.
Architecture
Diagramme d'architecture CQRS de séparation lecture-écriture avec des chemins de commande et de requête dédiés, PostgreSQL pour les écritures, Redis ou Elasticsearch pour les lectures optimisées, et une couche de synchronisation événementielle avec surveillance du décalage. Ce modèle démontre le principe fondamental du CQRS de séparer les modèles de lecture et d'écriture pour mettre à l'échelle et optimiser chaque chemin indépendamment. Idéal pour les applications avec des ratios lecture/écriture asymétriques où la performance des requêtes est critique.
Architecture
Diagramme d'architecture CQRS d'interface basée sur les tâches où le frontend capture l'intention de l'utilisateur sous forme de commandes explicites, les soumet de manière asynchrone avec des mises à jour optimistes, et reçoit des confirmations en temps réel via WebSocket lorsque le modèle de lecture est synchronisé. Ce modèle représente le pattern d'interface moderne qui remplace les formulaires CRUD par des commandes orientées intention, permettant des expériences utilisateur réactives avec cohérence à terme. Recommandé pour les équipes construisant des frontends réactifs sur des backends CQRS.