Architecture
A hexagonal architecture diagram showing the clean separation between domain core, inbound adapters (REST, GraphQL, CLI, message consumers), outbound adapters (PostgreSQL, Stripe, email, Redis), and the port interfaces that connect them. This template visualizes the ports and adapters pattern where the domain core has zero dependencies on infrastructure, making it fully testable and technology-agnostic. Foundational for teams adopting clean architecture principles in their codebase.
Full FlowZap Code
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)
}
Why This 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.
How It Works
- 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 | Hexagonal (Ports and Adapters) Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A clean architecture layers diagram showing the four concentric layers: Entities (domain), Use Cases (application), Interface Adapters (controllers, presenters, repositories), and Frameworks & Drivers (web server, database, cloud SDK). This template models Uncle Bob's Clean Architecture with the dependency rule where inner layers never depend on outer layers, ensuring the domain model remains pure and framework-independent. Essential reference for software architects enforcing architectural boundaries.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.