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.
Code FlowZap complet
Frontend { # Frontend BFF
n1: circle label:"User Action"
n2: rectangle label:"BFF Layer"
n3: rectangle label:"Compose UI Response"
n4: circle label:"Render UI"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Identity.n5.handle(top) [label="Auth Check"]
n3.handle(right) -> n4.handle(left)
}
Identity { # Identity & Access
n5: rectangle label:"Authenticate User"
n6: diamond label:"Authorized?"
n7: rectangle label:"Issue Access Token"
n8: rectangle label:"Deny Access"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="Yes"]
n6.handle(bottom) -> n8.handle(top) [label="No"]
n7.handle(bottom) -> Catalog.n9.handle(top) [label="Token"]
n8.handle(top) -> Frontend.n3.handle(bottom) [label="403"]
}
Catalog { # Product Catalog
n9: rectangle label:"Fetch Product Details"
n10: rectangle label:"Product Database"
n11: rectangle label:"Return Catalog Data"
n9.handle(right) -> n10.handle(left) [label="Query"]
n10.handle(right) -> n11.handle(left) [label="Products"]
n11.handle(bottom) -> Pricing.n12.handle(top) [label="Product IDs"]
n11.handle(top) -> Frontend.n3.handle(bottom) [label="Catalog JSON"]
}
Pricing { # Pricing & Promotions
n12: rectangle label:"Calculate Price"
n13: rectangle label:"Apply Promotions"
n14: rectangle label:"Return Final Price"
n12.handle(right) -> n13.handle(left) [label="Base Price"]
n13.handle(right) -> n14.handle(left) [label="Discounted"]
n14.handle(top) -> Frontend.n3.handle(bottom) [label="Price JSON"]
}
Fulfillment { # Order Fulfillment
n15: rectangle label:"Reserve Inventory"
n16: rectangle label:"Create Shipment"
n17: rectangle label:"Update Order Status"
n15.handle(right) -> n16.handle(left) [label="Reserved"]
n16.handle(right) -> n17.handle(left) [label="Shipped"]
n17.handle(top) -> Frontend.n3.handle(bottom) [label="Status Update"]
}
Pourquoi ce workflow ?
Decomposing a monolith by technical layers (UI, business logic, data) leads to distributed monoliths where every change requires coordinating multiple teams. Decomposition by business capability aligns service boundaries with organizational structure, enabling autonomous teams that own the full stack for their domain.
Comment ça fonctionne
- Step 1: Business capabilities are identified: Identity, Product Catalog, Pricing, and Fulfillment.
- Step 2: Each capability becomes an independent microservice with its own API and data store.
- Step 3: A Backend-for-Frontend layer aggregates data for specific client platforms.
- Step 4: The Identity service authenticates users and issues access tokens.
- Step 5: Product Catalog and Pricing services operate independently but share product IDs.
- Step 6: The Fulfillment service handles inventory reservation and shipment creation.
Alternatives
Decomposition by subdomain (DDD) is more rigorous but requires domain expertise. Decomposition by technical layer is simpler but creates coupling. This template provides a practical starting point for teams planning their first microservices decomposition.
Key Facts
| Template Name | Décomposition de microservices par capacité métier |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture d'événements de domaine montrant comment les racines d'agrégat émettent des événements de domaine qui sont distribués à la fois en interne aux gestionnaires locaux et en externe aux consommateurs d'événements d'intégration dans d'autres contextes bornés. Ce modèle représente le pattern d'événements DDD où la logique de domaine déclenche des effets de bord via un dispatcher d'événements propre, maintenant la séparation entre les préoccupations de domaine et d'infrastructure. Clé pour les équipes implémentant le Domain-Driven Design avec intégration événementielle.
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.
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 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.