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.
Code FlowZap complet
WriteModel { # Write Model
n1: circle label:"Incoming Command"
n2: rectangle label:"Command Handler"
n3: rectangle label:"Validate Against Aggregate"
n4: rectangle label:"Persist to Write Store"
n5: rectangle label:"Emit Domain Event"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left)
n3.handle(right) -> n4.handle(left) [label="Normalized"]
n4.handle(right) -> n5.handle(left) [label="After Commit"]
n5.handle(bottom) -> EventBus.n6.handle(top) [label="Publish"]
}
EventBus { # Event Bus
n6: rectangle label:"Route Event"
n7: rectangle label:"Guarantee Ordering"
n8: rectangle label:"Deliver to Projectors"
n6.handle(right) -> n7.handle(left) [label="Partition Key"]
n7.handle(right) -> n8.handle(left)
n8.handle(bottom) -> Projectors.n9.handle(top) [label="Fan-Out"]
}
Projectors { # View Projectors
n9: rectangle label:"Order Summary Projector"
n10: rectangle label:"Customer Dashboard Projector"
n11: rectangle label:"Analytics Projector"
n12: rectangle label:"Search Index Projector"
n9.handle(bottom) -> Views.n13.handle(top) [label="Build View"]
n10.handle(bottom) -> Views.n14.handle(top) [label="Build View"]
n11.handle(bottom) -> Views.n15.handle(top) [label="Build View"]
n12.handle(bottom) -> Views.n16.handle(top) [label="Build View"]
}
Views { # Materialized Views
n13: rectangle label:"Order Summary Table"
n14: rectangle label:"Customer Dashboard Cache"
n15: rectangle label:"Analytics Cube"
n16: rectangle label:"Elasticsearch Index"
n17: rectangle label:"Query API"
n18: circle label:"Fast Read Response"
n13.handle(right) -> n17.handle(left)
n14.handle(right) -> n17.handle(left)
n15.handle(right) -> n17.handle(left)
n16.handle(right) -> n17.handle(left)
n17.handle(right) -> n18.handle(left) [label="Sub-ms Latency"]
}
Pourquoi ce workflow ?
Different consumers need different views of the same data: dashboards need aggregations, search needs full-text indexes, and APIs need denormalized joins. Materialized views built from a single event stream allow each consumer to have a purpose-built read model without complex cross-service queries.
Comment ça fonctionne
- Step 1: The write model persists changes and emits domain events to the event bus.
- Step 2: The event bus guarantees ordered delivery to all registered projectors.
- Step 3: Each projector builds a specific materialized view: order summaries, dashboards, analytics cubes, or search indexes.
- Step 4: Views are stored in technology-appropriate stores (Redis, Elasticsearch, OLAP cubes).
- Step 5: The query API routes requests to the appropriate materialized view.
- Step 6: Views can be rebuilt from scratch by replaying the event stream.
Alternatives
Database views and materialized views work for single-database scenarios. GraphQL federation can compose data without materialized views. This template shows how to build multiple optimized read models from a single event stream.
Key Facts
| Template Name | Architecture CQRS de vues matérialisées |
| 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 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.
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.