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.
Code FlowZap complet
UI { # Task-Based UI
n1: circle label:"User Intent"
n2: rectangle label:"Render Task Form"
n3: rectangle label:"Capture User Intent as Command"
n4: rectangle label:"Submit Command"
n5: rectangle label:"Show Optimistic Update"
n6: circle label:"UI Updated"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="PlaceOrder"]
n3.handle(right) -> n4.handle(left) [label="Command DTO"]
n4.handle(bottom) -> CommandAPI.n7.handle(top) [label="POST /commands"]
n4.handle(right) -> n5.handle(left) [label="Optimistic"]
n5.handle(right) -> n6.handle(left)
}
CommandAPI { # Command API
n7: rectangle label:"Deserialize Command"
n8: rectangle label:"Authorize User"
n9: diamond label:"Idempotency Check"
n10: rectangle label:"Dispatch to Handler"
n11: rectangle label:"Return 202 Accepted"
n12: rectangle label:"Return 409 Duplicate"
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left)
n9.handle(right) -> n10.handle(left) [label="New"]
n9.handle(bottom) -> n12.handle(top) [label="Duplicate"]
n10.handle(right) -> n11.handle(left) [label="Queued"]
n11.handle(top) -> UI.n5.handle(bottom) [label="202"]
n10.handle(bottom) -> Domain.n13.handle(top) [label="Process"]
}
Domain { # Domain Model
n13: rectangle label:"Load Aggregate"
n14: rectangle label:"Execute Business Logic"
n15: rectangle label:"Persist State Change"
n16: rectangle label:"Emit Events"
n13.handle(right) -> n14.handle(left) [label="Current State"]
n14.handle(right) -> n15.handle(left) [label="New State"]
n15.handle(right) -> n16.handle(left) [label="Committed"]
n16.handle(bottom) -> QuerySync.n17.handle(top) [label="Async"]
}
QuerySync { # Query Synchronization
n17: rectangle label:"Update Read Model"
n18: rectangle label:"Push via WebSocket"
n19: rectangle label:"Invalidate Cache"
n17.handle(right) -> n18.handle(left) [label="Real-Time"]
n18.handle(top) -> UI.n6.handle(bottom) [label="Confirmed Update"]
n17.handle(right) -> n19.handle(left)
}
Pourquoi ce workflow ?
Traditional CRUD forms map poorly to complex business operations—a "Place Order" action involves validation, payment, inventory, and shipping, not a simple database row update. Task-based UIs capture user intent as explicit commands, enabling optimistic updates, async processing, and real-time confirmation via WebSocket.
Comment ça fonctionne
- Step 1: The UI renders a task form that captures user intent (e.g., "Place Order" not "Update Row").
- Step 2: User intent is serialized as a command DTO and submitted to the Command API.
- Step 3: The UI immediately shows an optimistic update while the command processes asynchronously.
- Step 4: The Command API checks idempotency, authorizes the user, and dispatches to the domain.
- Step 5: After processing, the read model is updated and a WebSocket push confirms the real state.
- Step 6: Cache invalidation ensures subsequent reads reflect the latest state.
Alternatives
Traditional CRUD forms are simpler but cannot express complex business intent. Polling for updates adds latency. Server-Sent Events are simpler than WebSockets for one-way updates. This template shows the full task-based UI with optimistic updates.
Key Facts
| Template Name | Architecture CQRS d'interface utilisateur basée sur les tâches |
| 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 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.
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.