Mastering Software Architecture Diagrams: From 4+1 Views to C4 Models

Introduction

This article presents a practical methodology for producing clear, self‑describing technical architecture diagrams that can be understood by all relevant stakeholders.

Definition of Architecture

System architecture is a conceptual model that maps functional and structural elements of objects or information and defines the relationships among those elements and with their environment.

Architecture is an abstract description of entities and the relationships between them, representing a set of design decisions.

Architecture combines structure with vision.

In the TOGAF framework, architecture is refined from strategy down to business, then to application, data, and technology layers. Practitioners typically concentrate on the application, data, and technology layers:

战略=>业务架构=>应用/数据/技术架构

Types of Architecture Diagrams

Architecture diagrams convey the overall system outline, component relationships, deployment topology, and evolution direction. Two widely adopted families are the 4+1 view and the C4 model.

4+1 View

The 4+1 view consists of five complementary perspectives that together form a complete architectural blueprint.

Context View

Shows the relationship between system participants (actors) and use cases, reflecting final requirements and interaction design. Typically expressed with a UML use‑case diagram.

Logical View

Depicts component relationships after functional decomposition, including constraints and boundaries. Usually modeled with UML component and class diagrams.

Physical View

Maps software components onto physical hardware nodes, guiding the deployment of the system onto compute resources.

Process (or Runtime) View

Illustrates communication sequences, data inputs/outputs, and functional/data flows, often using sequence diagrams or flowcharts.

Development View

Describes module breakdown and internal package design for developers, reflecting how the system is built.

C4 View

The C4 model uses a hierarchy of diagrams—System Context, Container, and Component—to describe a system’s static structure. Each diagram targets a specific audience.

System Context Diagram

Shows what the system is, who the users are, and how it fits into the existing IT environment. Audience includes developers, operations, and non‑technical stakeholders.

Container Diagram

Expands the context diagram by describing high‑level containers (applications, databases, services), their responsibilities, and interactions. Useful for developers and operations teams.

Component Diagram

Drills down into a specific container, detailing internal modules, their dependencies, and how they are organized for code delivery.

Creating Effective Architecture Diagrams

A good diagram should be self‑describing, consistent, accurate, and aligned with the codebase.

Identify the Audience

Before drawing, clarify who will read the diagram and what message must be conveyed. The diagram’s quality is judged by whether the intended audience receives the intended information.

Distinguish Diagram Elements

Use distinct shapes, colors, and line styles to encode different semantic meanings and avoid confusion. Complex systems usually require multiple coordinated diagrams rather than a single monolithic view.