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.
Code FlowZap complet
OrderContext { # Order Bounded Context
n1: rectangle label:"Order Aggregate"
n2: rectangle label:"Order Line Item"
n3: rectangle label:"Order Repository"
n4: rectangle label:"Order Service"
n1.handle(right) -> n2.handle(left) [label="Contains"]
n4.handle(right) -> n1.handle(left) [label="Manages"]
n4.handle(bottom) -> n3.handle(top) [label="Persists"]
n4.handle(bottom) -> ACL.n9.handle(top) [label="Integration Event"]
}
CustomerContext { # Customer Bounded Context
n5: rectangle label:"Customer Aggregate"
n6: rectangle label:"Address Value Object"
n7: rectangle label:"Customer Repository"
n8: rectangle label:"Customer Service"
n5.handle(right) -> n6.handle(left) [label="Has"]
n8.handle(right) -> n5.handle(left) [label="Manages"]
n8.handle(bottom) -> n7.handle(top) [label="Persists"]
n8.handle(bottom) -> ACL.n10.handle(top) [label="Integration Event"]
}
ACL { # Anti-Corruption Layer
n9: rectangle label:"Order-to-Shipping Translator"
n10: rectangle label:"Customer-to-Billing Translator"
n11: rectangle label:"Shared Kernel (Common Types)"
n12: rectangle label:"Context Map"
n9.handle(bottom) -> ShippingContext.n13.handle(top) [label="ShipmentRequested"]
n10.handle(bottom) -> BillingContext.n16.handle(top) [label="InvoiceRequested"]
n11.handle(right) -> n12.handle(left) [label="Defines"]
}
ShippingContext { # Shipping Bounded Context
n13: rectangle label:"Shipment Aggregate"
n14: rectangle label:"Tracking Number VO"
n15: rectangle label:"Shipping Service"
n13.handle(right) -> n14.handle(left) [label="Assigned"]
n15.handle(right) -> n13.handle(left) [label="Manages"]
}
BillingContext { # Billing Bounded Context
n16: rectangle label:"Invoice Aggregate"
n17: rectangle label:"Payment Entity"
n18: rectangle label:"Billing Service"
n16.handle(right) -> n17.handle(left) [label="Contains"]
n18.handle(right) -> n16.handle(left) [label="Manages"]
}
Pourquoi ce workflow ?
Large systems with a single unified model become increasingly complex as different teams interpret the same concepts differently. Bounded contexts establish clear boundaries where each context has its own ubiquitous language, data model, and team ownership—preventing model pollution and enabling independent evolution.
Comment ça fonctionne
- Step 1: The domain is decomposed into bounded contexts: Order, Customer, Shipping, and Billing.
- Step 2: Each context has its own aggregate roots, entities, and repositories.
- Step 3: An anti-corruption layer translates between context-specific models at integration points.
- Step 4: Integration events carry only the data needed by the consuming context.
- Step 5: A shared kernel defines common types used across multiple contexts.
- Step 6: The context map documents relationships (upstream/downstream, conformist, partnership) between contexts.
Alternatives
A single shared model is simpler for small teams but does not scale. Microservices without DDD boundaries often create distributed monoliths. This template shows the strategic DDD patterns for decomposing complex domains.
Key Facts
| Template Name | Architecture DDD des contextes bornés |
| 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 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 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 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é.