In Kruchten's "4+1" view model of software architecture, what are the five views and what does each one describe?

## Where the model comes from Philippe Kruchten published "Architectural Blueprints — The 4+1 View Model of Software Architecture" in *IEEE Software* (1995). The core idea is a reaction to a very common failure: a team draws **one** boxes-and-lines diagram and tries to make it answer every question anyone could ask about the system. The result satisfies nobody — the operations engineer cannot find the machines, the programmer cannot find the modules, the performance engineer cannot find the threads. The fix is **separation of concerns applied to documentation**. Instead of one diagram, you draw several *views*, each one a projection of the same system that deliberately keeps only what one audience cares about and deliberately throws the rest away. ## Vocabulary you need first - **System** — the actual thing that exists (or will exist). - **View** — a representation of the whole system from one perspective; a filtered picture. Not a part of the system, a *projection* of it. - **Stakeholder** — anyone with an interest in the system: end user, developer, tester, operator, security officer, project manager, customer paying for it. - **Concern** — a question or interest a stakeholder has ("can it survive a machine failure?", "where do I add a new payment method?", "what runs on which server?"). - **Notation** — the drawing language used (UML class diagram, sequence diagram, deployment diagram, plain boxes and arrows). ## The five views in detail ### 1. Logical view **Question it answers:** what functionality does the system provide, and how is that functionality decomposed? Contents: key domain abstractions (Order, Account, Shipment), their responsibilities, relationships and generalizations; sometimes layers or subsystems of *functionality*. Typical notation: UML class or package diagrams, ER-ish domain models. **Audience:** end users (indirectly, via analysts), business analysts, designers. Note it is about *functional* structure, not files. An abstraction in the logical view may be spread across several modules, and one module may implement several abstractions. ### 2. Process view **Question it answers:** what happens at runtime, and how do concurrent parts interact? Contents: processes, threads, tasks, queues, schedulers, the units of concurrency; how they communicate (messages, RPC, shared memory); synchronization points; where the throughput, latency, deadlock and starvation risks are. **Audience:** integrators, performance and reliability engineers. This is the view where non-functional properties like **response time**, **throughput**, **availability under load** and **fault isolation** actually become visible. Nothing in a class diagram tells you that two components run in the same thread and therefore block each other. ### 3. Development view (also called the implementation view) **Question it answers:** how is the source organized, and what depends on what at build time? Contents: modules, packages, libraries, layers with allowed dependency directions, the build/release units, ownership boundaries. **Audience:** programmers and the people managing the build, the repository layout and release process. This is where rules like "the domain layer must not depend on the web layer" live, and where team-to-module ownership (a Conway's-law concern) becomes explicit. ### 4. Physical view (also called the deployment view) **Question it answers:** what runs where? Contents: physical or virtual nodes (servers, containers, devices), networks and links, how processes from the process view are allocated onto those nodes, replication, failover topology, sizing. **Audience:** system engineers, operations/SRE, infrastructure. One logical system usually has *several* physical views — the developer laptop configuration, the test environment, the production topology — because the same software is deployed differently in each. ### 5. Scenarios — the "+1" **Question it answers:** do the other four views actually work together? A scenario is an instance of a use case, chosen because it is *architecturally significant*: it exercises the risky interactions, the peak load path, or a failure mode. You walk each scenario through the logical view (which abstractions participate), the process view (which threads and messages), the development view (which modules), and the physical view (which nodes). Scenarios play two roles: a **driver** (they motivate the design during discovery) and a **validator** (once the views exist, walking a scenario finds contradictions and gaps). They are also, deliberately, redundant with the other four views — that redundancy is what makes them able to detect inconsistency. ## Why the views are "largely independent" Each view can use its own notation, be maintained by different people, and evolve at its own pace. But they are not fully independent: an element in one view maps to elements in another (an abstraction is implemented by modules, modules are packaged into processes, processes are deployed to nodes). Those mappings are where most architectural bugs hide — for example, a logical decomposition that looks clean but forces two chatty components onto different machines. ## Trade-offs and common misuse - **Not all five are always needed.** Kruchten explicitly says the model is a menu, not a mandate. A single-process CLI tool has a trivial process and physical view; drawing them is waste. A distributed real-time system may need extra views. - **Cost of maintenance.** Every view is a document that can go stale. Views you do not maintain are worse than views you never drew, because readers trust them. - **Notation is not the point.** 4+1 is often taught as "five UML diagram types". The model is about *audiences and concerns*; UML is just one way to draw them. - **Overlap with newer models.** The C4 model (context/container/component/code) covers roughly the logical + development + a slice of the deployment concern with a strict zoom hierarchy, and adds a separate deployment diagram. Many teams today draw C4 and reserve the process view for the genuinely concurrent parts. ## How to use it in an interview Name the five, say what each shows *and who reads it*, then add the punchline: the views exist because different stakeholders have different concerns, and scenarios are what keep the separate views honest.