Architecture
Diagramme d'architecture data mesh avec propriété des données orientée domaine à travers les domaines Ventes, Marketing et Finance, chacun exposant des produits de données en libre-service via des API avec des SLA de qualité, gouvernés par une plateforme de données fédérée avec un catalogue partagé et un moteur de requêtes inter-domaines. Ce modèle représente le changement de paradigme des équipes data centralisées vers des produits de données possédés par les domaines, appliquant les principes des microservices à l'architecture de données. Essentiel pour les organisations mettant à l'échelle les opérations data au-delà des goulots d'étranglement des entrepôts de données centralisés.
Code FlowZap complet
SalesDomain { # Sales Data Domain
n1: rectangle label:"Sales Data Product Owner"
n2: rectangle label:"Sales Pipeline Dataset"
n3: rectangle label:"Self-Serve Data API"
n4: rectangle label:"Data Quality SLA"
n1.handle(right) -> n2.handle(left) [label="Owns"]
n2.handle(right) -> n3.handle(left) [label="Expose"]
n3.handle(right) -> n4.handle(left) [label="Monitor"]
n3.handle(bottom) -> Platform.n13.handle(top) [label="Register"]
}
MarketingDomain { # Marketing Data Domain
n5: rectangle label:"Marketing Data Product Owner"
n6: rectangle label:"Campaign Analytics Dataset"
n7: rectangle label:"Self-Serve Data API"
n8: rectangle label:"Data Quality SLA"
n5.handle(right) -> n6.handle(left) [label="Owns"]
n6.handle(right) -> n7.handle(left) [label="Expose"]
n7.handle(right) -> n8.handle(left) [label="Monitor"]
n7.handle(bottom) -> Platform.n13.handle(top) [label="Register"]
}
FinanceDomain { # Finance Data Domain
n9: rectangle label:"Finance Data Product Owner"
n10: rectangle label:"Revenue Reporting Dataset"
n11: rectangle label:"Self-Serve Data API"
n12: rectangle label:"Data Quality SLA"
n9.handle(right) -> n10.handle(left) [label="Owns"]
n10.handle(right) -> n11.handle(left) [label="Expose"]
n11.handle(right) -> n12.handle(left) [label="Monitor"]
n11.handle(bottom) -> Platform.n13.handle(top) [label="Register"]
}
Platform { # Self-Serve Data Platform
n13: rectangle label:"Data Product Catalog"
n14: rectangle label:"Federated Governance"
n15: rectangle label:"Shared Infrastructure"
n16: rectangle label:"Data Mesh Gateway"
n17: rectangle label:"Cross-Domain Query Engine"
n13.handle(right) -> n14.handle(left) [label="Policies"]
n14.handle(right) -> n15.handle(left) [label="Standards"]
n15.handle(right) -> n16.handle(left) [label="Access"]
n16.handle(right) -> n17.handle(left) [label="Federated Query"]
}
Pourquoi ce workflow ?
Centralized data teams become bottlenecks as organizations scale—every domain team waits for the central team to build their pipelines and models. Data mesh applies microservices principles to data, giving domain teams ownership of their data products while a shared platform provides self-serve infrastructure and federated governance.
Comment ça fonctionne
- Step 1: Each business domain (Sales, Marketing, Finance) owns its data as a product.
- Step 2: Domain data product owners are responsible for quality, documentation, and SLAs.
- Step 3: Data products are exposed through self-serve APIs registered in a central catalog.
- Step 4: Federated governance establishes shared standards for interoperability and compliance.
- Step 5: The self-serve data platform provides infrastructure for storage, processing, and access control.
- Step 6: A cross-domain query engine enables federated queries across all data products.
Alternatives
Centralized data warehouses are simpler but create bottlenecks. Data lakes without governance become data swamps. This template shows the data mesh approach for organizations scaling beyond centralized data teams.
Key Facts
| Template Name | Architecture Data Mesh |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
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.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.
Architecture
Diagramme d'architecture de migration Strangler Fig montrant le remplacement incrémental d'un monolithe legacy par de nouveaux microservices, utilisant une couche de routage pour répartir le trafic entre l'ancien et le nouveau système. Ce modèle représente la stratégie de migration éprouvée où les nouvelles fonctionnalités sont construites en microservices tandis que les endpoints legacy sont progressivement retirés. Essentiel pour les équipes modernisant des systèmes legacy sans réécriture risquée en big-bang.
Architecture
Diagramme d'architecture de découverte de services avec registre Consul ou Eureka, équilibrage de charge côté client, heartbeats de vérification de santé, et enregistrement/désenregistrement automatique des instances. Ce modèle visualise comment les microservices se localisent dynamiquement sans endpoints codés en dur, permettant une mise à l'échelle élastique et une infrastructure auto-réparatrice. Clé pour les équipes plateforme construisant une communication inter-services résiliente.