Skip to content
Software Architecture Guide

Context View

Explanation

Section titled “Explanation”

A context view shows how a system sits in its environment. The system itself is a black box. You do not show what is inside. You show the communication partners around it and the interfaces between them. An interface is a point where the system exchanges data with a partner.

Why it matters

  • Domain and technical interfaces to communication partners are among the most critical aspects of a system. The team must understand them fully.
  • Context is often left implicit. Nobody defines it during project initiation or requirements capture. A context view makes it explicit.
  • It describes the relationships, dependencies and interactions between the system and its environment.

Business and technical context

The business context shows which data the system exchanges with its environment. All stakeholders should be able to understand it. Diagrams work well, and a table can replace or complement them. See Business and Technical Context for more.

The technical context shows the channels and technical interfaces to neighbors. Many stakeholders base architectural decisions on these interfaces. Infrastructure or hardware designers often set them. A UML deployment diagram can show the channels to neighboring systems.

Practical advice

  • Mark risks directly in the context.
  • If many external systems are involved, group them by explicit criteria.
  • Keep detail low. The C4 system context diagram is a zoomed-out picture of the system landscape. It suits technical and non-technical people, inside and outside the team.

For the arc42 chapter that holds this view, see arc42 Context and Scope. For the C4 version, see System Context Diagram.

Example

Section titled “Example”

A team builds an online booking system. The context view shows one box for the booking system. Around it sit customers, a payment provider and an email service. Each line is labeled with the data exchanged, such as booking requests or payment confirmations. A second view shows the technical channels to each partner. The team marks the payment provider as a risk, because it depends on an outside party.

Trade-offs

Section titled “Trade-offs”

A context view keeps detail low on purpose. It says nothing about the inside of the system. Other views must cover that. With many external systems, the diagram gets crowded. Grouping partners by explicit criteria keeps it readable but hides individual partners.

Generic context view: the system as one box, with data labeled on each arrow.

Diagram source 
flowchart LR
  C[Customer] -->|booking request| S[Booking system]
  S -->|booking confirmation| C
  S -->|payment order| P[Payment provider]
  P -->|payment result| S
  S -->|email request| M[Email service]

Checks

Section titled “Checks”
  • The system appears as a black box with its communication partners around it.
  • The domain interfaces state which data are exchanged with the environment.
  • Technical interfaces and channels to neighboring systems are documented.
  • Risks are marked explicitly in the context.
  • Many external systems are grouped by explicit criteria.
Section titled “Related”

Sources

Section titled “Sources”