Understanding the 4+1 View Model: Five Perspectives to Master Software Architecture

Why multiple views?

Different stakeholders perceive only part of a system, similar to blind people touching different parts of an elephant. Users, developers, operations engineers, and testers each care about distinct aspects, so a single perspective yields an incomplete picture.

4+1 view model

Philippe Kruchten introduced the 4+1 view model in 1995 to describe software architecture from several angles. The model consists of four core views—Logical, Development, Process, Physical—and one Scenario view that ties the others together.

┌─────────────┐
               │   Scenario   │
               │ (Use‑case)   │
               └──────┬──────┘
                        │
      ┌─────────────────┼─────────────────┐
      │                 │                 │
 ┌────▼─────┐   ┌──────▼───────┐   ┌─────▼─────┐
 │ Logical   │   │ Process      │   │ Physical   │
 │ (What)    │   │ (How it runs)│   │ (Where)   │
 └──────┬────┘   └──────┬───────┘   └──────┬────┘
        │                │                │
        └───────┬────────┼───────────────┘
                ▼        
            ┌───────┐
            │Development│
            │ (Code)   │
            └───────┘

Logical view

Question answered: What functionality does the system provide?

Stakeholders: End users, business analysts, product managers.

Description: Functional decomposition, module responsibilities, class and interface design.

用户系统
├── 认证模块
│   ├── 登录
│   └── 注册
├── 用户信息模块
│   ├── 查看个人信息
│   └── 修改个人信息
└── 权限模块
    ├── 角色管理
    └── 权限分配

Typical diagrams: class diagram, package diagram, functional module diagram.

Development view

Question answered: How is the code organized?

Stakeholders: Developers, build engineers.

Description: Source‑code structure, directory layout, dependency relationships, build configuration.

project/
├── src/
│   ├── main/
│   │   ├── java/
│   │   │   └── com/company/
│   │   │       ├── user/   # 用户模块
│   │   │       ├── order/  # 订单模块
│   │   │       └── product/ # 商品模块
│   │   └── resources/
│   └── test/
├── pom.xml          # Maven配置
└── build.gradle     # Gradle配置

Typical diagrams: package diagram, module dependency graph, project structure diagram.

Process view

Question answered: What does the system look like at runtime?

Stakeholders: System integrators, performance engineers, operations staff.

Description: Process/thread model, concurrency control, synchronization mechanisms, performance characteristics.

┌─────────────────────────────────────────────────┐
│          Application Server                      │
├─────────────────────────────────────────────────┤
│                                                 │
│  ┌─────────────┐     ┌─────────────┐            │
│  │ Thread 1    │     │ Thread 2    │            │
│  │ ┌─────────┐│     │ ┌─────────┐│            │
│  │ │Handler 1││     │ │Handler 2││            │
│  │ └─────────┘│     │ └─────────┘│            │
│  └─────────────┘     └─────────────┘            │
│                                                 │
│  ┌─────────────────────────────────────────┐   │
│  │          Connection Pool                │   │
│  │  ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐   │   │
│  │  │Conn│ │Conn│ │Conn│ │Conn│ │Conn│   │   │
│  │  └────┘ └────┘ └────┘ └────┘ └────┘   │   │
│  └─────────────────────────────────────────┘   │
└─────────────────────────────────────────────────┘

Typical diagrams: process diagram, thread‑model diagram, concurrency diagram.

Physical view

Question answered: Where is the system deployed?

Stakeholders: Operations engineers, system administrators, network engineers.

Description: Hardware topology, network architecture, deployment strategies, fault‑tolerance.

┌─────────────────────────────────────────────────────┐
│               Internet                              │
│                     │                               │
│      ┌──────────▼──────────┐                        │
│      │   Nginx Cluster    │                        │
│      │ (Load‑balancing+SSL)│                        │
│      └──────────┬──────────┘                        │
│                 │                                   │
│   ┌─────────────────┼─────────────────┐           │
│   │                 │                 │           │
│ ┌─▼─┐          ┌─▼─┐          ┌─▼─┐               │
│ │S1 │          │S2 │          │S3 │               │
│ │(Primary)│   │(Replica)│   │(Replica)│           │
│ └─┬─┘          └─┬─┘          └─┬─┘               │
│   │               │               │               │
│   └─────────────────┼─────────────────┘           │
│                     │                               │
│      ┌──────────▼──────────┐                        │
│      │   MySQL Cluster     │                        │
│      │ (Primary‑Replica)  │                        │
│      └─────────────────────┘                        │
└─────────────────────────────────────────────────────┘

Common diagrams: deployment diagram, network topology diagram, infrastructure diagram.

Scenario view

Question answered: How does the system work?

Stakeholders: All participants.

Description: Key business processes, use‑case implementations, cross‑module interactions.

用户登录场景：

1. 用户输入用户名密码
   ↓
2. 前端发送登录请求
   ↓
3. 网关路由到认证服务
   ↓
4. 认证服务验证密码
   ↓
5. 生成 JWT Token
   ↓
6. 返回 Token 给前端
   ↓
7. 用户登录成功

Typical diagrams: use‑case diagram, sequence diagram, activity diagram.

Relationships between views

┌─────────────────────────────────────────────────────┐
│               Scenario View                         │
│   (connects all views, describes key scenarios)      │
└─────────────────────────────────────────────────────┘
        │          │          │
        ↓          ↓          ↓
 ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
 │ Logical View│ │ Process View│ │ Physical View│
 │ (What)      │ │ (How it runs)│ │ (Where)      │
 └──────┬──────┘ └──────┬──────┘ └──────┬──────┘
        │          │          │
        └───────────────────────┼───────────────────────┘
                                ↓
                         ┌─────────────┐
                         │ Development │
                         │ (Code)      │
                         └─────────────┘

Applying the 4+1 view model in a project

Identify the Scenario – recognize key use‑cases and describe their essential flow.

Design the Logical view – decompose functionality and define module boundaries.

Design the Development view – structure source code, manage dependencies, and specify build configuration.

Design the Process view – model the runtime architecture and concurrency.

Design the Physical view – plan deployment architecture and infrastructure.

Advantages

Comprehensiveness : Covers all architectural dimensions.

Targeted : Each view serves specific readers.

Consistency : Scenario view ties everything together.

Maturity : Proven over decades.

Disadvantages

Complexity : Large documentation effort.

Maintenance cost : Multiple views must stay synchronized.

Over‑engineering : Small projects may not need all five views.

Typical usage scenarios

Requirements analysis – use Logical view + Scenario view.

Technical design – use all four core views.

Code development – focus on Development view.

Testing – combine Process view + Scenario view.

Deployment – use Physical view.

Performance tuning – use Process view.

Fault investigation – combine Physical view + Process view.