C4 Model
Context, container, component and code as four separate diagrams.
4 to work through
-
intermediate
A team adopts a layered diagram model and produces every level for every part of the system. What has gone wrong, and how should the model be used?
2 min answer -
intermediate
A team produces detailed component diagrams for every service and they are all stale within a sprint. Which diagram levels are worth maintaining by hand?
2 min answer -
intermediate Multiple choice
If you could maintain only one architecture diagram, which would it be and why?
2 min answer -
advanced Multiple choice
An 80-engineer platform group keeps 60 hand-drawn architecture diagrams in a drawing tool and wants a single text model in version control that renders context and container views. Delivery cannot pause for this. Which first step is both useful and reversible?
3 min answer
3 terms in this topic
Abstraction Level Discipline
Keeping each diagram to a single level of zoom, and providing separate diagrams for each level rather than one diagram attempting all of them.
practiceC4 Model in Practice
Four nested levels of diagram — context, container, component, code — whose value is controlling altitude rather than the notation itself.
conceptDiagram Maintenance Economics
The rule that a diagram earns its maintenance cost only when it explains something hard to derive from source - which is why structure diagrams below…
2 artifacts you would hand over
Component Diagram
The inside of one runnable unit — its major code-level groupings, their responsibilities and what each one talks to.
Structural ViewContainer Diagram
One level inside the system boundary — the separately deployable and runnable pieces, each named with the technology it is built on.
Neighbouring topics
Architecture Communication
General material on communicating architecture.
Architecture Diagrams
Choosing an audience and refusing to mix levels of abstraction.
Context Diagrams
The system as one box, with its users and external systems.
Sequence Diagrams
Ordered message exchange, and walking the failure of each arrow.
Data-Flow Diagrams
Following the data across trust boundaries rather than the calls.
Deployment Diagrams
What runs where, in which zone, behind which boundary.
Communicating Threat Models
Making risk legible to people who will fund or accept it.
Writing Decision Records
Context, alternatives and consequences, written once and never edited.
Technical Proposals
A written argument circulated before the decision feels made.
Architecture Reviews
Reviewing early enough to influence rather than to veto.
Presenting to Executives
Decision first, cost, risk, and what happens if we do nothing.
Presenting to Engineers
Mechanism, alternatives rejected, and what you are unsure about.
Explaining Trade-offs
Naming what was given up, and the condition that would change it.
Handling Disagreement
Arguing from consequences, and escalating in the room.
Negotiation
Trading on interests rather than positions, with priced options.
Documentation Practice
Keeping documents close to the code and honest about staleness.
Presentation Skills
Structure, pacing and the slide that carries the decision.
Written Communication
Writing that survives being read without you in the room.
Facilitation
Running a design session that reaches a decision.