This content originally appeared on Level Up Coding – Medium and was authored by Salman Hoque
Software system design is about communication, not just code. A design that makes sense to one team may be meaningless to another.
Imagine trying to capture an entire complex system in a single diagram, like drawing a building’s floor plan, electrical wiring, and plumbing on one sheet of paper. The result would be confusing, overloaded, and ultimately unhelpful. That’s the problem the 4+1 View Model set out to solve.
Philippe Kruchten’s 4+1 View Model proposes multiple concurrent views, each focused on a specific concern. It recognises that different stakeholders care about different things: users focus on interactions, developers on code structure, operations on runtime behaviour, and architects on system integrity.
In this Article, we’ll dive into what each view in the 4+1 View Model represents and how they come together to tell the story of a software system. We’ll also explore how to get started using them in a greenfield or brownfield system without feeling overwhelmed, and how to adapt the model with new views when the system requires more clarity.
Clarify stakeholders’ roles and speak their language using targeted views
Describing intricate systems from a single perspective often fails to reflect their true complexity. A single view can’t accommodate the range of questions raised by teams working across product, infrastructure, engineering, and operations.
The 4+1 View Model enables clearer communication, faster alignment, and better design decisions across the software development lifecycle. The result isn’t just a collection of diagrams, but a shared architectural language. This language balances both functional and non-functional aspects of the system and evolves with the needs of its stakeholders.
Designing a software system is a lot like designing and building a house. If you tried to explain your entire house using just one drawing, you’d end up with something messy and confusing. That’s why architects use multiple diagrams, each tailored to a specific audience and purpose.
In the 4+1 View Model, there are four core views: Logical View, Development View, Process View, and Physical View. Then there is “+1,” which is the Scenario View that glues together the other views to deliver a use case or customer journey. Let’s understand each of these views a bit better.
Logical View
You can think of software Logical View as the layout of rooms – kitchen, bedrooms, bathroom, and living area – how they connect. It describes the features, like whether it’s a studio apartment or a house with enough bedrooms. In software, this translates to the core domains and their interactions.
The Logical View provides a clear, high-level understanding of customer workflows, processes, and their interactions. Its primary focus is to build an understanding of the system’s capabilities and to provide a high-level structure and behaviour.
This view allows us to identify a trigger event (e.g., when an item is purchased) and the subsequent steps. From there, it helps us identify entities, feature sets that work together, and bounded contexts that encapsulate a set of responsibilities. For example, an e-commerce system could have bounded contexts like Product Catalog, Shopping Cart, Order Processor, and Shipment. A bounded context like Product Catalog would be responsible for listing, viewing, and searching products and would highlight the entities it owns.
Focus: Functional requirements and design (what the system should do)
Primary stakeholders: Architects, Developers, Product Owners, Designers
Possible Diagrams: Event Storming Board, Service/Bounded context map
Some discussions questions:
- How does each user workflow work?
- How does the system handle complex business rules?
- What are the bounded contexts?
- Are there any shared entities or anti-patterns?
Development View
In a house, an architectural drawing shows how it’s built, including load-bearing walls, materials, aesthetics, and capabilities. Similarly, in software, the Development View maps to code structure, module boundaries, team responsibilities, deployment, and testing.
Software engineers likely spend most of their time in the Development View, since it’s closest to the daily development and deployment of code. This view illustrates the codebase structure, covering system architectures like monoliths, layered architectures, or micro-services, and code organisation patterns such as DDD, MVC, and SOLID. It explains the software’s modularity, including modules, packages, libraries, and layers. Software management, versioning, and deployment can also be included. This view addresses internal requirements that are critical for ease of development and long-term system maintainability. It’s no wonder we spend so much time here. The participants in this view usually share a common language, which I think provides a high level of comfort.
Focus: Software architecture, management, code organisation from a development standpoint
Primary stakeholders: Tech leads, Engineers, QA
Possible Diagrams: Codebase Pattern, API Contract, Module or Service Diagrams, CI/CD Pipeline Diagram
Useful Discussions:
- What pattern does the team use to develop the software?
- How are APIs documented and shared?
- How do teams collaborate?
Process View
Following our house analogy, this view is similar to how people use the house — getting in, turning on lights, cooking, or using the restrooms. In software, this means running the code in production and addressing dynamic aspects like concurrency, communication between processes or threads, timing, performance, and scalability.
This view might get ignored in the startup world and only becomes a priority when a sudden surge of users makes the system unusable. It covers runtime behaviour and interactions, illustrating how a user request traverses multiple services, or how services communicate via messaging. Concurrency, asynchronous messaging, eventual consistency, and retries are all runtime behaviour that belong in the process view.
Using our home analogy, if multiple people needed to use the restroom simultaneously and there was only one, the house wouldn’t be able to serve everyone. This view is crucial for addressing non-functional requirements like performance, scalability, and availability. For example, if a web server uses a thread-per-request model, increasing server traffic would require increasing the number of running instances. In a micro-service environment, this view could show the running services and how they work together at runtime to deliver the end result.
Focus: Runtime behaviour and concurrency
Primary stakeholders: Tech leads, Engineers
Recommended Diagrams: Sequence Diagram, Activity Diagram (e.g async workflows or orchestration), Run Time Processes Diagram
Useful Discussions:
- How does data flow between services?
- Where are the bottlenecks or latency risks?
- What is synchronous vs asynchronous?
Physical View
My house analogy has probably stretched enough, it starts to break down a little here, as everything in the house has a physical presence, unlike software. But bear with me. Let’s think of this view as the basic needs: electrical wires, water pipes, power outlets, heating, cooling, or how power and water reach each room. In software, this corresponds to infrastructure, servers, containers, and networks.
This view describes how the software is mapped onto the hardware or infrastructure. Think of this as the systems engineer’s concern, dealing with topology, deployment, and physical connections. It shows nodes, servers, devices, network topologies, virtual private clouds (VPCs), DNS, and which software components run on which nodes.
The physical view might show cloud infrastructure, container orchestration, application servers, databases, and how they are interconnected. It shows how services are grouped on nodes or containers. It may also include information about scaling — though scaling could also be seen as part of the process view. Essentially, it shows the distributed software system: which service runs where and how they connect, including third-party dependencies. This view also helps with the non-functional requirements, as they are directly related to the underlying hardware, such as system availability, reliability, and throughput.
Focus: Infrastructure hardware and topology
Primary stakeholders: Architects, SRE, Tech leads, Engineers
Recommended Diagrams: Deployment Diagrams (nodes, clusters, services), Network Topologies / Cloud Resource Maps (VPC, DBs, queues, etc.), Third- party service mapping
Useful Discussions:
- Where are services deployed (nodes or containers)?
- How is failover handled?
- What’s the auto scaling setup?
Scenario View
Now, let’s consider everyday tasks at home as stories or use cases — for example, “guests come over”, “someone takes a shower”, or “there’s a power outage” Walking through these real-life use cases helps us validate our design, in this case, our software system design, ensuring all the views work together smoothly.
You might be thinking — “Why 4+1 views?” and “Why not 5 views?”. In the 4+1 View Model, the scenario view isn’t an architectural view in the same way as the Logical View or Physical View. Instead, it’s a method for validating communication between all the other views. Think of the scenario view as a script or story that walks through the architecture to validate that it can actually work together to execute real-world use cases.
The “+1” view consists of a set of critical scenarios or use cases — for example, “User places an order” or “User purchases a product”, that traverses the elements of the four core views. The scenario view doesn’t introduce new structure, instead, it threads through the other views to show how the pieces come together to fulfill requirements. Requirements are often initially captured as use cases or user stories, which then serve as the basis for the design activities documented in the logical view.
Focus: Validates the architecture using key use cases
Primary stakeholders: Everyone — Product, Design, QA, Architects, Engineers etc.
Recommended Diagrams: User story maps, End-to-End flow diagrams, Event Storming Boards
Useful Discussions:
- Does this scenario touch multiple services?
- What’s the happy path vs failure modes?
- How are retries, timeouts, and eventual consistency handled?
Thread views to make the system traceable from user to server
The 4+1 View Model helps us connect different perspectives to create a cohesive narrative, one that flows from the user’s intention to the code that makes it happen. When users interact with interfaces, a complex network of services, APIs, and queues is triggered behind the scenes. By connecting architectural views — from Scenario (user actions) to Logical (domain models) to Process (runtime flows) to Development (code) to Physical (infrastructure) — we create a clear and easy-to-follow path through the system. This traceability helps everyone understand the system and its parts.
As we build, improve, and maintain software systems, we constantly make decisions, like “Should we refactor this service?” or “Can we extract this as a service with another team?” These decisions have technical, operational, and even human consequences. The 4+1 Views allow us to make these decisions with context and traceability, so we can understand the impact of a change on the system.
This layered approach allows us to question each step of development and make choices that fit the need. It guides us through business use-cases and supports them with a sound system. For example, “User saves an item for later purchase” could be a simple Scenario View. In the Logical View, we could map how the event is triggered and what happens after. At this stage, it could help us see if we need to change our domain model. In the Process View, we could ask if it should be a synchronous or asynchronous workflow, or if it needs its own process. Based on the process communication pattern, we’ll design APIs or messages for queues in the Development View. How we deploy this impacts the Physical view; it might require new services or database changes. Each view influences the others. A better understanding of each layer means we’re solving the problem at the right level of our software stack.
Let’s consider another common use case: “Extract and Unify Notification Service.” This is relevant because we often find different notification services in multiple domains, each with its own custom version (probably because we all seem to like building them). A high-level Logical View would show us that we’re complicating our system by duplicating infrastructure resources. We might realise that notification is a supporting domain, and we’re investing too much in it. This could make moving it to a third-party an easier decision. That would simplify our Process, Development, and Physical layers, even though they may now point to third-party services handling notifications.
Connecting the views of a system is like creating a map. For every major feature or important requirement, there should be a corresponding element in each view. This traceability ensures that the views aren’t isolated; they work together to fulfil the same requirements.
Make it approachable, easy to follow and easy to change
As we explore the 4+1 architectural view model, you might be wondering about the right level of detail to include. Striking a balance is key. It’s a trade-off between usefulness, future value, and the effort required to maintain it.
A guiding principle is to focus on architecturally significant areas and omit the rest. Each view should capture the major design decisions and structures. For example, in the logical view, we don’t need to detail how login/authorization or notifications are handled for every domain. These can be addressed within the context of the Auth or Notification domain itself. Similarly, in the Development view, instead of documenting every class, we can focus on the higher-level patterns (e.g., DDD, Clean/Hexagonal/Onion architecture) that the application predominantly follows.
The 4+1 view model isn’t a rigid requirement to produce five separate documents or diagrams for every project. It’s a pragmatic model. Each view can be represented using various diagrams, and sometimes views can be combined. For a small or straightforward project, like a mobile app, explicitly separating all views might not be necessary — Scenario, Logical, and Development views might suffice. If the Platform team provides a standard infrastructure template, we could combine the Process and Physical views for simplicity.
A common pitfall is creating overly detailed and complex architectural views, or turning the process into a bureaucratic exercise. This can make the documentation difficult to maintain and keep current. Generating massive, verbose, low-level documents that aren’t actually useful to the audience turns them into shelfware that nobody reads. The system evolves, but the documentation remains static. Keeping it simple and focusing on significant areas ensures that the team can easily reference, discuss, and evolve the documentation without significant overhead.
Let’s clarify this with a couple of examples
For a greenfield project – the Scenarios View is a great place to start. Here’s why:
- It anchors the architecture in real business goals and user needs.
- It helps uncover the most critical system behaviour before committing to a specific structure or technology.
- It ensures that all other views (Logical, Process, Development, Physical) are driven by real use cases, not assumptions.
- It brings all stakeholders together early — from business to tech — to build a shared understanding.
One of the best ways to get started is by having an Event Storming session with engineers, product, design, or any stakeholder, including marketing, sales, and support. This helps walk through key business flows or user journeys, uncovering real-world use cases and validating end-to-end flows. It highlights interactions between actors and events and helps define business capabilities. The outcome of Event Storming often leads to diagrams like context maps or domain maps, which are core to the Logical View. It also establishes a shared domain language.
For a brownfield project – the Logical View is a great place to start, assuming a strong understanding of the Scenarios View. Here’s why –
- The system already exists, so we need to understand its structure and be able to explain it before we can change or extend it.
- It solidifies understanding of the Scenarios View with the domain boundaries, events, actors, and entities.
- It establishes a shared domain language and vocabulary for teams trying to refactor, scale, or modularise parts of the system.
Creating multiple views or diagrams doesn’t have to be a complex, lengthy process. A significant portion can be achieved with a few workshops with the team, which makes keeping them up-to-date simpler.
As systems evolve, new views can bring back clarity
Software systems are Socio-Technical Systems. It’s “Socio” because it involves people, their own rules, processes, priorities, and ideas. These human elements translate into a “Technical System” that serves a specific purpose. This system isn’t static; it evolves based on user feedback, requiring continuous adaptation and change. In such a dynamic environment, initial architecture documentation, however detailed, represents only a snapshot in time.
The 4+1 View Model provides an excellent foundation for capturing core stakeholder concerns. However, the views it defines aren’t always sufficient. As systems evolve and stakeholder needs shift, new perspectives may become essential. As the system evolves, or as new stakeholders join, we might need additional views to provide clarity. For example:
- Regulated industries (finance, healthcare, gov-tech), where the system handles sensitive user data and must meet legal/compliance standards, might need a Security/Audibility View.
- AI/ML-powered systems with model training and inference pipelines could use an ML-Model Lifecycle View.
- Larger organisations with Platform teams might create a Platform View or a CI/CD View that extends the Development or Physical View
The challenge of designing software systems is often a challenge of communication. We’ve explored how each view aligns with a different stakeholder concern and how threading them together can bring traceability, insight, and shared understanding. The 4+1 View Model is not just for documentation, but also for collaboration, allowing us to ask better questions and surface assumptions.
On your next feature planning, whether planning a greenfield project, trying to tame a legacy system, or refactoring for scale – try out a simple view, perhaps begin with a Logical View to define the system’s structure, or a Scenario View to anchor use cases. Let the other views grow organically.
Ultimately, it doesn’t need to capture everything, just enough to bring clarity, make the system approachable, and build a shared language for communication.
If you enjoyed this article and would like to read more, follow me on Medium or LinkedIn for updates on my latest posts!
Software Blueprint: Using 4+1 Views to Align Stakeholders was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding – Medium and was authored by Salman Hoque