Skip to main content

Views and Viewpoints: C4, 4+1, arc42

What This Concept Is​

No single diagram explains a system. A system has many concerns - structure, runtime behavior, deployment, data flow, domain model, security - and each concern wants its own picture. The vocabulary for this is:

  • Viewpoint. A category of concern ("the structural concerns of my system"). Independent of any specific system.
  • View. A diagram that addresses a viewpoint for a specific system ("the structure of this payments platform").

Three widely used frameworks formalize which viewpoints an architecture document should include:

  • C4 model (Simon Brown). Four zoom levels: Context, Container, Component, Code. Optimized for hierarchical structural communication; explicitly does not cover deployment or runtime except as supplementary diagrams.
  • 4+1 view model (Philippe Kruchten). Five views: Logical, Process, Development, Physical (Deployment), and Scenarios ("+1" ties them together). The classic academic framework.
  • arc42 template. A complete documentation structure with 12 sections, including goals, constraints, context, solution strategy, building blocks, runtime, deployment, crosscutting concerns, decisions, quality, risks, and glossary.

Each framework is a checklist for "did we show enough?" They are not competitors; they are different answers to the same question at different scales.

Why It Matters Here​

Architects who know only one framework miss concerns the framework does not emphasize. A pure C4 user might ship beautiful Context/Container diagrams and never address runtime. A pure 4+1 user might produce four diagrams when two would do.

Knowing all three gives you a menu. For small-to-mid projects, C4 is usually enough. For a full architecture packet a regulated industry will accept, arc42 is closer. For an academic review, 4+1 is the expected language.

This concept is supporting because the act of diagramming well (Concept 14) matters more than the framework choice. But the framework choice tells you which diagrams you still owe the reader.

Concrete Example​

The same IoT platform documented under each framework.

C4.

  1. Context: one diagram showing "IoT platform" as a box, surrounded by users (homeowners, installers), external systems (weather service, partner integrations), and regulators.
  2. Container: zoom in. The platform breaks into mobile app, public API, device gateway, rules engine, storage, dashboard. Each is a deployable unit.
  3. Component: zoom in on the rules engine. Shows its internal components (rule store, evaluator, scheduler, alert dispatcher).
  4. Code (optional): class-level detail, usually skipped for architecture documentation.

4+1.

  1. Logical: domain entities (Home, Device, Rule, Event) and their relationships.
  2. Process: runtime view. Shows threads and processes, how events flow from device to rules engine to action.
  3. Development: how the code is organized - packages, modules, repositories.
  4. Physical / Deployment: how the containers map to infrastructure - regions, zones, clusters, nodes.
  5. Scenarios (+1): walk through "homeowner opens the app and the garage door opens" across the other four views.

arc42. 1-3. Goals, constraints, context and scope (roughly overlaps with C4 Context). 4. Solution strategy (one-paragraph "we chose this shape because"). 5. Building block view (roughly C4 Container/Component). 6. Runtime view (roughly 4+1 Process). 7. Deployment view (roughly 4+1 Physical). 8. Crosscutting concepts (logging, auth, error handling). 9. Architecture decisions (short log of key decisions). 10. Quality scenarios (pointed at the top-3 characteristics). 11. Risks and technical debt. 12. Glossary.

Same system, three different tables of contents. Notice the overlaps; notice what each adds.

Common Confusion / Misconception​

"C4 is the modern replacement for 4+1." Not quite. C4 explicitly scopes itself to structural views. 4+1 and arc42 cover runtime, deployment, and governance. C4's strength is what it leaves out.

"Pick one framework and use it religiously." Using a framework as a checklist is fine; using it as a religion is a bad look. Real systems often produce C4 diagrams plus an arc42 decision log plus a runtime diagram borrowed from 4+1.

"More diagrams = better documentation." A view is useful only if a reader can change their behavior based on it. A diagram that nobody reads is worse than no diagram, because it suggests the work is done.

"The framework tells me what to draw." The framework tells you what concerns deserve a view. It does not tell you how to draw one that is actually useful. That is Concept 14.

How To Use It​

Before drawing, pick:

  1. Who is the reader? A new engineer, a regulator, an on-call operator, a senior exec. Different readers need different views.
  2. What decision or question does the diagram support? A diagram that does not support a decision is decoration.
  3. Which framework's checklist is closest to the reader's needs? C4 for engineers joining; arc42 for governance; 4+1 for research/review settings.

A reasonable default for most teams:

  • C4 Context + Container as the baseline, always.
  • A runtime/process diagram for the highest-traffic or most-failure-prone flow.
  • A deployment diagram when the target is non-trivial (multi-region, on-prem, hybrid).
  • An arc42-style decision log and quality scenarios regardless of diagramming framework.

Check Yourself​

  1. Which framework explicitly does not prescribe a deployment view?
  2. What does arc42 include that C4 does not?
  3. Pick a system. Which two viewpoints does it have well-documented today? Which are weakest?

Mini Drill or Application​

Pick a system you have touched. Produce a short table:

ViewpointCovered?ArtifactReader
Context.........
Container / Building block.........
Component.........
Runtime / process.........
Deployment.........
Decisions / quality.........

The empty cells are the next documentation work. If all six are full but no one reads them, the problem is elsewhere.

Read This Only If Stuck​