Architecture & structure · Model

C4 model

Explain a software architecture through a small set of consistent levels of detail.

Introductory · 3 drills · Reviewed 2026-10-24

What it helps you do

Give readers an appropriate architectural map without mixing people, whole systems, applications, and implementation details indiscriminately.

Starting knowledge: No specialist knowledge is required.

  • Choose a level of zoom before choosing boxes.
  • Name each element’s responsibility and relevant technology.
  • Label relationships with their meaning and direction.

The problem it came from

Simon Brown created C4 to help software teams communicate architecture. Its name refers to context, containers, components, and code.

The official model separates architectural abstractions from the notation used to draw them. Teams should use the views that answer real questions rather than produce every level automatically.

Work through an example

STARTING POINT
User → cloud → service → function → database → company
APPLYING THE APPROACH
Context: a reader uses the document workspace; the workspace sends email through a notification system.
Container: browser application → workspace API → document store.
Component: the API contains authorization and document-access components.
Code: inspect selected implementation elements only when useful.
  • The context view treats the workspace as one system.
  • The container view opens that boundary without mixing in functions.
  • A sequence diagram can separately explain authorization before retrieval.

A context view you can read

Document workspace system contextA reader uses the document workspace. The workspace sends confirmation messages through an external notification system. Internal components are outside this view.ReaderDocument workspaceNotificationsusessends via

A reader uses the document workspace. The workspace sends confirmation messages through an external notification system. Internal components are outside this view.

Where it helps. Where it stops.

Use it when

  • Introducing a system to a newcomer or inspecting its boundaries.
  • A diagram mixes cloud vendors, individual functions, and whole organizations at one unexplained level.

Potential benefits

  • Consistent zoom levels support different reader questions.
  • Explicit boundaries and responsibilities expose missing dependencies.

Limits and common mistakes

  • A C4 container means an application or data store, not necessarily a Docker container.
  • A structural view does not prove runtime order, security enforcement, or reliability.
Applying it with AI

The prompt below asks for this structure. It does not guarantee accuracy, complete coverage, better learning, or conformance to a standard. Treat those outcomes as separate checks.

Practise the judgment

Try a choice, inspect a boundary, then explain a case yourself. Hints and answers are available whenever you need them.

DRILL 01 Not attempted

A C4 container is always what?

Choose one answer
Hint

Separate model vocabulary from deployment tooling.

Explained answer

Best answer for this case: An application or data store in the architectural model

C4 uses container as an architectural abstraction. Its meaning is broader than containerization technology.

DRILL 02 Not attempted

Which view answers whether authorization happens before fetching a document?

Choose one answer
Hint

What kind of information is time order?

Explained answer

Best answer for this case: An interaction or sequence view

Call order is behavioral information. A dependency arrow alone does not establish the sequence.

DRILL 03 Not attempted

Describe a context view for a library reservation service without listing internal functions.

Hint

Could a reader understand the boundary without seeing implementation names?

Explained answer & self-review rubric

Show members using the reservation service and the service interacting with external catalog or notification systems. State each participant’s responsibility and the scope of the service boundary.

  • Keep system-level abstractions
  • Include people and external systems
  • Label relationships

Take it into your own work

Manual template

Use this structure yourself, with a colleague, or in your preferred writing tool.

# C4 view
Question and audience:
Level: context / container / component / code
System boundary:
Elements: name | responsibility | type or technology
Relationships: source | verb | destination | protocol if relevant
External dependencies:
Excluded detail:

Review the result

  • Are elements at a consistent level?
  • Does every arrow have a meaningful label?
  • Are deployment and behavior claims supported separately?
Use this approach with your own AI tool
Help me apply C4 model to the material below.
Reader and existing knowledge: [describe]
Task and desired outcome: [describe]
Use these principles: Choose a level of zoom before choosing boxes.; Name each element’s responsibility and relevant technology.; Label relationships with their meaning and direction..
Preserve source facts, identifiers, quantities, conditions, exceptions, and uncertainty.
Separate supplied facts from assumptions. Ask for missing information instead of inventing it.
Explain your representation choices and provide a review checklist. Do not claim formal compliance or correctness from formatting alone.
Material: [paste only information you are permitted to share]
Download prompt

Go to the source

History and the underlying approach are grounded in these references. Examples, prompts, and practice cases here are original educational adaptations. Edition-specific details should be checked against the referenced publication.

Last editorial review: 2026-10-24. An overview is not certification, and this guide is not a reproduction of a standard.