C4 model: audience-driven zoom and supporting views

C4 — notation- and tooling-independent approach to visualising software architecture at hierarchical zoom levels: System Context, Container, Component и Code. Supporting Landscape, Dynamic и Deployment diagrams answer other questions. Official guidance says use only levels that add value; Context/Container are sufficient for many teams, not mandatory proof of architecture correctness.

Что утверждает паттерн — и чего он не гарантирует

• C4’s core static abstractions are software system, container, component and code; supporting views include landscape, dynamic and deployment.
• Official guidance says not all four levels are required: create views that add value; component diagrams are specifically optional.
• A C4 component is grouped functionality inside a container, not a separately deployable service.
• Good notation is explicit: title/scope/legend, element type/responsibility/technology and labelled directional relationships.

Границы и компоненты

Сценарии

Render a System Context view

For a broad audience, show Customer, Administrator, Commerce and Payment Provider with named relationships; do not mix containers or database internals into this view.

Проверяемый исход: Every person/external system relationship, including Administrator to Commerce, is visible and labelled.

Zoom to containers

For technical audiences, show Web, API, Orders DB and external Payment Provider with protocols and responsibilities. A C4 container means application/data-store deployable unit, not a Docker-only concept.

Проверяемый исход: Container boundaries and inter-process relationships are clear without component/code noise.

Zoom to a useful component

A team investigating order logic renders components inside API. The component is in-process and not portrayed as independently deployed.

Проверяемый исход: Component view exists only because it answers a concrete design/ownership question.

Supplement static structure

A Dynamic view orders one use-case interaction; a Deployment view maps containers to environment instances. Neither replaces the static model or runtime telemetry.

Проверяемый исход: Sequence and environment topology are explicit without claiming C4 verifies production behavior.

Failure, concurrency и evolution checklist

• Derive or review diagrams against source/deployment/service catalog to detect drift.
• Do not mix abstraction levels without explicit scope and legend.
• Include people and external systems directly related to the scope, including admin paths.
• Use runtime traces and deployment configuration as separate evidence; diagrams alone cannot prove behavior.

Метрики, units и допущения

• Diagram count is not architecture quality; optimize for questions answered and review freshness.
• Drift can be tracked as model relationships missing from observed/configured topology and vice versa, with review timestamp.
• Large views should be split by focus and audience rather than scaled indefinitely; there is no universal box-count threshold.

Числа здесь — размерностные формулы или явно помеченные учебные inputs. Паттерн архитектуры сам по себе не задаёт SLA, throughput, latency или fault tolerance.

Связанные темы

[CONCEPT]architecture-decision-records

[CONCEPT]clean-architecture

Первичные источники

• https://c4model.com/
• https://c4model.com/diagrams
• https://c4model.com/diagrams/checklist
• https://c4model.com/diagrams/component

Scope note

C4 communicates a model. It does not prescribe delivery process/team structure or prove security, resilience, code conformance, runtime sequence or deployed topology without additional evidence.