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.
Full FlowZap Code
External { # External Layer (Frameworks & Drivers)
n1: rectangle label:"Express/Fastify Web Server"
n2: rectangle label:"PostgreSQL Driver"
n3: rectangle label:"Redis Client"
n4: rectangle label:"AWS SDK"
n1.handle(bottom) -> Interface.n5.handle(top) [label="HTTP Request"]
n2.handle(bottom) -> Interface.n8.handle(top) [label="DB Connection"]
n3.handle(bottom) -> Interface.n8.handle(top) [label="Cache"]
}
Interface { # Interface Adapters Layer
n5: rectangle label:"Controller"
n6: rectangle label:"Presenter"
n7: rectangle label:"DTO Mapper"
n8: rectangle label:"Repository Implementation"
n5.handle(right) -> n7.handle(left) [label="Map Input"]
n7.handle(bottom) -> UseCase.n9.handle(top) [label="Request Model"]
n6.handle(top) -> External.n1.handle(bottom) [label="View Model"]
n8.handle(bottom) -> UseCase.n12.handle(top) [label="Implements"]
}
UseCase { # Use Cases Layer (Application)
n9: rectangle label:"Create Order Use Case"
n10: rectangle label:"Get Order Use Case"
n11: rectangle label:"Cancel Order Use Case"
n12: rectangle label:"Order Repository Interface"
n9.handle(bottom) -> Entity.n13.handle(top) [label="Call Domain"]
n10.handle(bottom) -> Entity.n13.handle(top) [label="Query"]
n11.handle(bottom) -> Entity.n14.handle(top) [label="Cancel"]
n9.handle(right) -> n12.handle(left) [label="Persist"]
n10.handle(top) -> Interface.n6.handle(bottom) [label="Output"]
}
Entity { # Entities Layer (Domain)
n13: rectangle label:"Order Aggregate Root"
n14: rectangle label:"Order Item Entity"
n15: rectangle label:"Money Value Object"
n16: rectangle label:"Order Status Enum"
n13.handle(right) -> n14.handle(left) [label="Contains"]
n14.handle(right) -> n15.handle(left) [label="Uses"]
n13.handle(bottom) -> n16.handle(top) [label="State"]
}
Why This Workflow?
Frameworks and databases change frequently, but business rules should remain stable. Clean Architecture enforces the dependency rule—inner layers never depend on outer layers—ensuring that the most important code (domain logic) is the most stable and testable, while infrastructure details are easily replaceable.
How It Works
- Step 1: The Entities layer defines domain models, value objects, and business rules.
- Step 2: The Use Cases layer implements application-specific business logic.
- Step 3: The Interface Adapters layer converts data between use case format and external format.
- Step 4: The Frameworks & Drivers layer contains web servers, database drivers, and cloud SDKs.
- Step 5: Dependencies point inward: controllers depend on use cases, use cases depend on entities.
- Step 6: The repository interface is defined in the use case layer but implemented in the adapter layer.
Alternatives
Traditional MVC mixes concerns across layers. Hexagonal architecture is similar but uses different terminology. Vertical slice architecture organizes by feature instead of layer. This template provides the canonical Clean Architecture reference.
Key Facts
| Template Name | Clean Architecture Layers |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
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.
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.