Architecture
Diagramme d'architecture hexagonale montrant la séparation nette entre le cœur de domaine, les adaptateurs entrants (REST, GraphQL, CLI, consommateurs de messages), les adaptateurs sortants (PostgreSQL, Stripe, email, Redis) et les interfaces de ports qui les connectent. Ce modèle visualise le pattern ports et adaptateurs où le cœur de domaine n'a aucune dépendance sur l'infrastructure, le rendant entièrement testable et agnostique technologiquement. Fondamental pour les équipes adoptant les principes d'architecture propre dans leur base de code.
Code FlowZap complet
InboundAdapters { # Inbound Adapters (Driving)
n1: rectangle label:"REST Controller"
n2: rectangle label:"GraphQL Resolver"
n3: rectangle label:"CLI Command Handler"
n4: rectangle label:"Message Consumer"
n1.handle(bottom) -> Ports.n5.handle(top) [label="Port: CreateOrder"]
n2.handle(bottom) -> Ports.n5.handle(top) [label="Port: CreateOrder"]
n3.handle(bottom) -> Ports.n6.handle(top) [label="Port: RunReport"]
n4.handle(bottom) -> Ports.n6.handle(top) [label="Port: ProcessEvent"]
}
Ports { # Ports (Interfaces)
n5: rectangle label:"Inbound Port: OrderUseCase"
n6: rectangle label:"Inbound Port: ReportUseCase"
n7: rectangle label:"Outbound Port: OrderRepository"
n8: rectangle label:"Outbound Port: PaymentGateway"
n5.handle(bottom) -> Core.n9.handle(top) [label="Implement"]
n6.handle(bottom) -> Core.n10.handle(top) [label="Implement"]
}
Core { # Domain Core (Hexagon)
n9: rectangle label:"Order Service"
n10: rectangle label:"Report Service"
n11: rectangle label:"Domain Model (Entities)"
n12: rectangle label:"Business Rules (Value Objects)"
n9.handle(right) -> n11.handle(left) [label="Use"]
n10.handle(right) -> n11.handle(left) [label="Use"]
n11.handle(right) -> n12.handle(left) [label="Enforce"]
n9.handle(bottom) -> Ports.n7.handle(top) [label="Call Port"]
n9.handle(bottom) -> Ports.n8.handle(top) [label="Call Port"]
}
OutboundAdapters { # Outbound Adapters (Driven)
n13: rectangle label:"PostgreSQL Repository"
n14: rectangle label:"Stripe Payment Adapter"
n15: rectangle label:"Email Notification Adapter"
n16: rectangle label:"Redis Cache Adapter"
n7.handle(bottom) -> OutboundAdapters.n13.handle(top) [label="Implements"]
n8.handle(bottom) -> OutboundAdapters.n14.handle(top) [label="Implements"]
n13.handle(right) -> n15.handle(left)
n14.handle(right) -> n16.handle(left)
}
Pourquoi ce workflow ?
When business logic depends directly on frameworks, databases, and external services, it becomes impossible to test in isolation and expensive to change infrastructure. Hexagonal architecture inverts these dependencies through ports (interfaces) and adapters (implementations), keeping the domain core pure and technology-agnostic.
Comment ça fonctionne
- Step 1: Inbound adapters (REST controllers, GraphQL resolvers, CLI handlers) receive external input.
- Step 2: Adapters call inbound port interfaces defined by the domain core.
- Step 3: The domain core implements business logic using entities and value objects.
- Step 4: When the domain needs infrastructure, it calls outbound port interfaces.
- Step 5: Outbound adapters (PostgreSQL repository, Stripe payment, email sender) implement these ports.
- Step 6: Swapping infrastructure requires only changing the adapter, not the domain code.
Alternatives
Layered architecture is simpler but allows infrastructure dependencies to leak into business logic. Clean Architecture adds more layers but follows the same dependency inversion principle. This template shows the hexagonal approach with concrete adapter examples.
Key Facts
| Template Name | Architecture hexagonale (Ports et Adaptateurs) |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme des couches d'architecture propre montrant les quatre couches concentriques : Entités (domaine), Cas d'utilisation (application), Adaptateurs d'interface (contrôleurs, présentateurs, repositories) et Frameworks & Drivers (serveur web, base de données, SDK cloud). Ce modèle représente la Clean Architecture d'Uncle Bob avec la règle de dépendance où les couches internes ne dépendent jamais des couches externes, garantissant que le modèle de domaine reste pur et indépendant du framework. Référence essentielle pour les architectes logiciels imposant des frontières architecturales.
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.