Skip to content
Software Architecture Guide

Architectural View

Explanation

Section titled “Explanation”

A software system has many aspects. Describing all of them in one model gives a picture that is hard to understand. Such a model also rarely shows the most important features of the architecture.

An architectural view avoids this. Each view covers one aspect of the system. Together, the views describe the whole architecture.

View and viewpoint

A viewpoint is a reusable set of patterns, templates and conventions for building one type of view. Architects do not have to invent the content of every view from scratch. A viewpoint also states whose concerns its views reflect. (A stakeholder is anyone with an interest in the system. See Stakeholder.)

Why views help

  • Separation of concerns. Packing many aspects into one picture clouds communication. It also lets aspects that should be independent become intertwined. Separate views prevent this. See Separation of Concerns.
  • Communication. Different stakeholder groups can go straight to the parts of the description that match their concerns.
  • Managing complexity. The architect treats each significant aspect on its own, one after another.
  • Developer focus. The architecture description is the foundation of system design. It matters especially to developers.

Views in arc42

The arc42 template uses views directly. Its building block view shows the static decomposition of the system. It is mandatory in every architecture documentation. It lets you talk with stakeholders at an abstract level, without revealing implementation details. See arc42 Architecture Documentation Template.

Example

Section titled “Example”

A team documents an online shop. One view shows the main parts of the system and how they divide the work. A business owner can read it without seeing any implementation details. Other views cover other aspects, such as how the parts are installed. Each reader opens the view that matches their concerns, and no single picture has to show everything.

Trade-offs

Section titled “Trade-offs”

The facts here describe the benefits of views. They do not cover costs, such as keeping several views consistent with each other.

Checks

Section titled “Checks”
  • Each view states which stakeholders’ concerns it addresses.
  • No single all-in-one model tries to show every aspect of the system.
  • The building block view is present and shows the static decomposition of the system.
  • The building block view stays abstract and does not expose implementation details.
Section titled “Related”

Sources

Section titled “Sources”