- 5 minutes to read

Example C4 Diagrams

Each example page below shows a rendered diagram and its copy-paste Mermaid code side by side. To use any example in Nodinite, copy the Mermaid markup and follow the Creating Your First C4 Diagram import walkthrough to create a Diagram Set, import the markup, and bind elements to your Repository.

Understanding C4 Diagram Types

The C4 model defines four zoom levels, each answering a different architectural question:

Level Name Audience Question Answered
L0 System Landscape Executives, enterprise architects How do all systems in the organisation relate?
L1 Context Everyone What is the system and who uses it?
L2 Container Technical teams How is the system internally structured?
L3 Component Developers What is inside a specific container?
L4 Code Senior developers What is the detailed implementation?

L1, L2, and L3 are bound together by hierarchical zoom: you pick a system in L1, zoom into it for L2, then pick a container and zoom into it for L3.

Operational Diagram Types

Beyond the zoom hierarchy, two additional diagram types capture runtime and deployment perspectives:

Diagram Type Question Answered
Dynamic How do systems interact at runtime for a specific workflow?
Deployment Where is the system deployed and on what infrastructure?

These are not zoom levels — they show different operational perspectives on the same architecture.

In a Diagram Set, all diagram types coexist. An L0 Landscape, L1 Context, two L2 Containers, a Dynamic, and a Deployment diagram can all live in the same set — each automatically cross-linked through shared Repository entity bindings.

Examples

Example Best For
L1: System Context Diagram Everyone — who uses the system, what it interacts with
L2: Container Diagram Technical teams — internal structure and technology choices
L3: Component Diagram Developers — modules and interactions inside a container
System Landscape Diagram Enterprise architects — all systems in the organisation
Dynamic Diagram Troubleshooting — runtime sequence for a specific workflow
Deployment Diagram DevOps/Ops — infrastructure and service placement

Quick Reference

Your Question Diagram Audience
"Who uses the system and what does it interact with?" L1: Context Everyone
"How is the system structured internally?" L2: Container Technical teams
"What modules make up this container?" L3: Component Developers
"How do multiple enterprise systems relate?" System Landscape Enterprise architects
"How do systems interact during a specific workflow?" Dynamic Technical teams
"Where and how is the system deployed?" Deployment DevOps, operations

What Goes Where — Nodinite Entity Cheat Sheet

When you import a C4 diagram, Nodinite resolves each node against your Repository. The C4 level determines which entity type a node can bind to. Using the wrong names at the wrong level causes duplicate entries with the same name but different entity types — for example, a Service and an Integration both named INT1337-RCV-Order-Incoming.

Diagram C4 Node Shape Binds to Nodinite What to name it Example
L0 / L1 Person, System, System_Ext, SystemDb, SystemQueue System Application, platform, or actor names ERP, Portal, Customer
L2 Container, ContainerDb, ContainerQueue Service Service / endpoint names INT1337-RCV-Order-Incoming
L2 Container for a platform or portal System The platform name — same as its L1 node Portal, ERP
L3 Component, ComponentDb, ComponentQueue Integration Code-level artefact names — not Service names Order Validator, Deduplication Guard
Dynamic Container, ContainerDb, ContainerQueue Service Same as L2 INT1337-RCV-Order-Incoming
Deployment Container, ContainerDb, ContainerQueue Service Same as L2 INT1337-RCV-Order-Incoming
All Boundary(...) Domain Business domain names Sales, Planning, Logistics
All _Ext suffix shapes System (external) Third-party / partner names ERP Adapter, Trading Partner Event Bus

The most common import mistake is using Nodinite Service names (e.g. INT1337-*) as L3 Component node labels. Because L3 Components bind to Integrations — not Services — this creates a new Integration entity with the same name as an existing Service, resulting in two different things with identical names. L3 Component nodes must describe implementation artefacts inside the container (controllers, validators, repositories, publishers), never the service endpoints themselves.

Level Summary at a Glance 

L0 / L1   ──  System names         →  bind to  System
L2        ──  Service / endpoint names  →  bind to  Service  (or System for platforms/portals)
L3        ──  Code-level class/handler names  →  bind to  Integration
Dynamic   ──  Same as L2
Deployment──  Same as L2
Boundary  ──  Domain names          →  bind to  Domain

See C4 Model vs Nodinite Concept Mapping for the full property-level reference.

Key Takeaway: Diagrams Tell Different Stories

L0, L1, L2, and L3 form a drill-down hierarchy, navigable through automatic drill-through links within a Diagram Set:

L0 Landscape: "Here are all our enterprise systems"
↓ focus on Order System in L0 → jump to its L1
L1 Context: "Here's the Order System"
↓ zoom into Order System → jump to its L2
L2 Container: "It's built from Web App, APIs, Database, Message Bus"
↓ zoom into Order API → jump to its L3
L3 Component: "The Order API contains Controller, OrderService, OrderRepository"

Dynamic and Deployment diagrams are operational perspectives — they show different views on the same architecture, not deeper zoom levels.

Next Step

Creating Your First C4 Diagram walks through creating a Diagram Set, importing Mermaid markup, and binding nodes to your Repository using the import wizard.