Why One Architecture Diagram Isn’t Enough? Using the 4+1 View Model to Clarify a System

01 Why Multiple Architecture Views Are Needed

Using an internet‑hospital as an example, patients care about registration, payment and refunds; designers care about module responsibilities; integration engineers worry about concurrency when hundreds of thousands of users book simultaneously; programmers need to know module boundaries; operations staff need deployment locations. Packing all this into one diagram makes it unreadable, while oversimplifying fails to satisfy any stakeholder, so architects must describe the system from several angles.

02 Viewpoint vs View

The concepts are likened to photographing the same hospital building from different positions: firefighters capture fire exits, patients capture entrances, construction workers capture load‑bearing structures, network engineers capture racks and cables. Viewpoint defines the camera position, lens and shooting rules—i.e., "how to look". View is the resulting photo—i.e., "what is seen".

Viewpoint is the rule of "how to look", and view is the result of "what is seen".

Multiple views, textual descriptions, interface constraints and architectural decisions together form a complete architecture description , comparable to an entire photo album rather than a single picture.

03 What Is the 4+1 View Model

The model consists of five views: Logical, Process, Development, Physical, and Scenario (+1). The mnemonic "功、并、码、机，场景来验证" maps to functionality (logical), concurrency (process), code organization (development), machines (physical), and a scenario that validates the others.

04 Logical View

The logical view focuses on system functions, responsibilities, classes, objects, subsystems and domain modules. In the internet‑hospital, modules include patient, doctor, scheduling, registration, payment, consultation, prescription and notification. The registration module creates and cancels appointments; the scheduling module manages doctor slots; the payment module handles charges and refunds.

Which functional parts compose the system and what does each part do?

05 Process View

The process view examines runtime processes, threads, communication, synchronization, performance and throughput. For example, at 8 am many patients simultaneously try to book the same doctor, requiring multiple registration service instances, message‑queue‑based asynchronous notifications, inter‑service communication and fault handling.

When the system runs, who works with whom, and how do they communicate and synchronize?

06 Development View

The development view (also called implementation view) concerns source code, modules, packages, components, dependencies, compilation, build and configuration management. The hospital’s code can be split into registration service, scheduling service, payment adapter, notification component and a common security module. Dependencies are explicit—for instance, the registration module may only invoke the scheduling interface, never modify the scheduling database directly.

Where is the code placed and which modules does it depend on?

07 Physical View

The physical (deployment) view describes servers, networks, nodes, data‑centers, topology and hardware‑software mapping. Example: user requests enter a gateway cluster; three instances of the registration service run; Redis, Kafka and the database each form high‑availability clusters; core services are deployed across availability zones.

On which machines and network nodes are the software components finally deployed?

08 Scenario View

The scenario (or use‑case) view shows how a real business flow runs, e.g., a patient completing a registration: the patient selects a doctor, the system queries the schedule, concurrently decrements the slot, creates the registration record, processes payment, sends a notification and returns the result. This scenario validates that the logical responsibilities are complete, the process view handles concurrency, the development view implements the flow, and the physical view can sustain peak traffic.

Thus the scenario view is the "+1" that drives, links and verifies the other four views.

09 Terminology Variations

In exams the same concept may appear under different names: development view = implementation view, physical view = deployment view, scenario view = use‑case view. Recognize the underlying meaning rather than relying on a fixed term.

10 Architecture Views vs UML Diagrams

UML diagrams are a language for expressing content; an architecture view may contain many UML diagrams, text, tables and constraints. A single sequence diagram can illustrate logical collaboration or process communication, but a view is defined by its audience and aspect, not by the diagram type alone.

11 Memory Palace for the Five Views

A mnemonic places five landmarks—A’s desk, L’s desk, water dispenser, sink and restroom—each associated with a vivid image that reminds the learner of scenario, logical, process, development and physical views respectively.

12 Self‑Test

Questions and answers reinforce the distinction between viewpoint and view, and the mapping of concurrency, code organization, deployment and scenario to their respective views, as well as the purpose of the "+1" view.

13 Minimal Recall Card

Viewpoint is the rule of "how to look", view is the result of "what is seen". Logical sees functions, process sees concurrency, development sees code, physical sees machines, scenario validates. Development also called implementation, physical also called deployment, scenario also called use‑case.