Introduction to the four core levels (Context, Container, Component, Code) and three supporting views (Landscape, Dynamic, Deployment)
The true power of the C4 Model lies in its elegant, zoomable hierarchy. Rather than forcing everything into a single overwhelming diagram, the model organizes architecture visualization into distinct levels of abstraction. You start at the highest, broadest view and progressively “zoom in” to reveal more detail — exactly as needed for the audience and purpose.
This hierarchy ensures clarity, focus, and scalability: each diagram has one clear responsibility, and you never show more (or less) than is useful at that moment.
The Four Core Levels (the “C4”)
- Level 1: System Context Diagram
- What it shows: Your entire software system as one single box, surrounded by its users (Persons) and any external systems it interacts with.
- Key elements: People (users, actors), external software systems, and high-level relationships.
- Level of detail: Very high — no technologies, no internal structure.
- Primary audience: Non-technical stakeholders, executives, product managers, new team members, auditors.
- Typical questions answered: What is the system? Who uses it? What does it connect to externally? Why does it exist?
- When to use: Almost always — this is the starting point for any architecture discussion or onboarding.
- Level 2: Container Diagram
- What it shows: Zooms inside the software system to reveal the major runnable or deployable units — web applications, mobile apps, APIs/backends, databases, message brokers, file systems, microservices, serverless functions, etc.
- Key elements: Containers, the technologies chosen for each, and how containers communicate (protocols, APIs, queues, etc.).
- Level of detail: Medium — shows high-level technical building blocks and their interactions, but not internal implementation.
- Primary audience: Developers, architects, DevOps/operations teams, technical stakeholders.
- Typical questions answered: What are the major deployable parts? Which technologies are used? How do they talk to each other?
- When to use: Whenever you need to understand or communicate the high-level technical architecture.
- Level 3: Component Diagram
- What it shows: Zooms into one specific container to reveal its internal logical building blocks — modules, services, libraries, subsystems, bounded contexts, web controllers, business logic layers, data access components, etc.
- Key elements: Components, their responsibilities, and the interfaces/relationships between them.
- Level of detail: Detailed but still conceptual — focuses on logical structure and design decisions, not code-level classes or methods.
- Primary audience: Developers working inside that container, architects reviewing modularity or refactoring plans.
- Typical questions answered: How is this container internally structured? What are the key modules/services? Where are the boundaries and interfaces?
- When to use: Selectively — only when the internal structure of a container adds meaningful value (e.g., complex domains, legacy monoliths being decomposed, critical services).
- Level 4: Code Diagram
- What it shows: The most granular view — implementation details inside a single component (or small set of components).
- Key elements: Classes, interfaces, enums, data structures, relationships (inheritance, composition, dependencies), or even database schemas (ERDs).
- Level of detail: Very detailed — often uses UML class diagrams, sequence diagrams, or auto-generated code structure views.
- Primary audience: Developers implementing or maintaining specific code.
- Typical questions answered: How is this component actually implemented in code? What classes handle what?
- When to use: Rarely and judiciously — only when code-level clarity is genuinely required (e.g., onboarding to a tricky area, security audits of critical code paths). Most teams stop at Level 3.
The Three Supporting Views
These are not part of the core “zoom” hierarchy but provide essential complementary perspectives:
- System Landscape Diagram A high-level, enterprise-wide view showing multiple software systems and their relationships across the organization. Think of it as a “zoomed-out” System Context diagram that includes many internal systems, not just one. Used for: portfolio visibility, enterprise architecture overviews, identifying integration points.
- Dynamic Diagram Focuses on runtime behavior rather than static structure. Shows how elements (persons, containers, or components) interact for a specific use case, scenario, or workflow — similar to a simplified UML sequence or collaboration diagram. Used for: explaining key flows, message exchanges, event-driven behavior, onboarding to business processes.
- Deployment Diagram Maps containers (Level 2) to physical or virtual infrastructure — servers, cloud regions, Kubernetes clusters, load balancers, networks, availability zones, etc. Shows runtime topology, scaling, redundancy, and infrastructure choices. Used for: DevOps/operations discussions, capacity planning, security reviews, disaster recovery planning.
Together, these seven diagram types (4 core levels + 3 supporting views) form a complete yet lightweight toolkit. You choose only the views you need — there is no obligation to create all of them.
This flexible, hierarchical structure is what makes the C4 Model so powerful: it adapts to the size of your system, the maturity of your team, and the needs of your stakeholders, while keeping every diagram focused, understandable, and maintainable.