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

Introduction

Hello, I am a senior architect. Many people are dazzled by the myriad colorful architecture diagrams shown by large tech companies and wonder how to present their own system clearly. This article shares a methodology for creating understandable technical diagrams.

What Is Architecture?

Architecture reflects the relationship between objects/information and their functional and formal elements.

It is an abstract description of system entities and their relationships, representing a series of decisions.

Architecture is both structure and vision.

TOGAF Architecture Layers

In TOGAF, architecture is refined from the strategic level downwards: Strategy → Business Architecture → Application/Data/Technology Architecture. While executives focus on strategy and business architecture, practitioners usually concentrate on the application, data, and technology layers.

Architecture Diagram Types

Business Architecture: Defined by business architects, it influences organizational and technical structures.

Application Architecture: Designed by application architects to control complexity, ensure performance, security, stability, and other non‑functional attributes.

Technical Architecture: Describes required services and the technology components that implement them, as well as their interactions.

Data Architecture: Covers data models, distribution, flow, lifecycle, and management.

Purpose of System Architecture Diagrams

System architecture diagrams abstractly depict the overall outline of a software system, the relationships and constraints among components, physical deployment, and evolution direction. Good diagrams help stakeholders understand and follow architectural decisions, solving communication barriers, achieving consensus, and reducing ambiguity. The popular 4+1 view and C4 view models are introduced.

4+1 View Model

1. Scenario View

Describes the relationship between system participants and use cases, reflecting final requirements and interaction design, usually expressed with a use‑case diagram.

2. Logical View

Shows component relationships, constraints, and boundaries after decomposing software functionality, typically using UML component and class diagrams.

3. Physical View

Maps software components to physical hardware, guiding deployment on compute nodes.

4. Process View

Describes communication sequences, data input/output, and functional/data flows, usually with sequence or flow diagrams.

<img src="https://mmbiz.qpic.cn/mmbiz_png/b96CibCt70iaajvl7fD4ZCicMcjhXMp1v6UXcBIdyPOYfUfaibicSXbZSrkFL9jwZRTUz8aKA1zXq1GDV8Z7uXeep6w/640"/><img src="https://mmbiz.qpic.cn/mmbiz_png/b96CibCt70iaajvl7fD4ZCicMcjhXMp1v6UXcBIdyPOYfUfaibicSXbZSrkFL9jwZRTUz8aKA1zXq1GDV8Z7uXeep6w/640"/><img src="https://mmbiz.qpic.cn/mmbiz_png/b96CibCt70iaajvl7fD4ZCicMcjhXMp1v6UXcBIdyPOYfUfaibicSXbZSrkFL9jwZRTUz8aKA1zXq1GDV8Z7uXeep6w/640"/><img src="https://mmbiz.qpic.cn/mmbiz_png/b96CibCt70iaajvl7fD4ZCicMcjhXMp1v6UXcBIdyPOYfUfaibicSXbZSrkFL9jwZRTUz8aKA1zXq1GDV8Z7uXeep6w/640"/>

5. Development View

Describes module partitioning, internal package composition, and serves developers, reflecting the implementation process.

C4 Model

The C4 model uses containers, components, and code to describe a software system's static structure. It is easy to draw and clearly indicates the intended audience and purpose of each diagram.

1. System Context Diagram

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

2. Container Diagram

Expands the system context by describing high‑level containers (applications, databases, micro‑services) and their responsibilities, interactions, and technology choices. Audience includes developers and operations staff.

3. Component Diagram

Drills down into a specific container, showing internal modules, services, and their dependencies, primarily for developers.

Designing Effective Architecture Diagrams

Before drawing a diagram, identify its audience and the information to convey. A good diagram should be self‑describing, consistent, accurate, and aligned with the codebase. Use distinct shapes, colors, and line styles to differentiate elements and avoid semantic confusion.