Skip to content
Software Architecture Guide

Essential Architecture Views (Context, Component, Runtime, Distribution)

Explanation

Section titled “Explanation”

An architecture view is one picture of a system that answers one kind of question. Four views cover most needs: context, component (building block), runtime, and distribution (deployment). They map onto arc42 sections and onto the C4 model.

Context view. It shows the system as a black box and delimits it from its communication partners. It also specifies the external interfaces. This is arc42 section 3, “Context and Scope”. It can separate business context from technical context (see Business and Technical Context). In the business context, all stakeholders should understand which data the system exchanges with its environment. In C4, this is the system context level.

Component view. It shows the static decomposition of the system into building blocks. The result is a hierarchy of black boxes and white boxes. arc42 compares it to a house floor plan. Blocks can be modules, components, subsystems, classes, interfaces or packages, plus their dependencies. This is arc42 section 5, and it is mandatory.

Runtime view. It shows how instances of building blocks do their job and communicate while the system runs. arc42 asks for a representative selection of architecturally relevant scenarios, not every possible flow. This is arc42 section 6.

Distribution view. It shows the environment the software runs in. arc42 recommends UML deployment diagrams for it, nested when the infrastructure is complex. Other node-and-channel diagrams are acceptable for hardware stakeholders. This is arc42 section 7.

Relation to C4. C4 uses a hierarchy of diagrams: system context, containers, components, and code. It does not depend on one notation. Its core diagrams can be drawn in UML with packages, components and stereotypes. UML diagrams tend to lack descriptive text, so add it.

Example

Section titled “Example”

A team builds an online booking tool. The context view shows the tool as one box, with customers and a payment provider around it, and labels the data exchanged. The component view splits the tool into blocks such as booking, accounts and notifications. The runtime view walks through one scenario: a customer books and pays. The distribution view shows which servers host each block.

Trade-offs

Section titled “Trade-offs”

Four views do not cover everything. The facts here only describe what each view shows, so a document still needs other sections, such as decisions and quality requirements. UML diagrams can be drawn for C4, but they tend to lack descriptive text. The runtime view shows only a representative selection of scenarios. That keeps it readable but leaves some flows undocumented.

Checks

Section titled “Checks”
  • The context view shows the system as a black box with its communication partners and external interfaces.
  • The building block view is present and shows a hierarchy of black boxes and white boxes.
  • The runtime view covers a representative selection of architecturally relevant scenarios.
  • The deployment view uses a UML deployment diagram, or another node-and-channel diagram for hardware stakeholders.
  • Any UML versions of C4 diagrams carry descriptive text.
Section titled “Related”

Sources

Section titled “Sources”