The 4+1 view is an architectural blueprint often used in modern software development. As early as 1995, Phillip Krutchen proposed this concept in his masterpiece The “4+1” View Model of Software Architecture. He draws an analogy with the different architectural perspectives in the construction industry, such as structure, plumbing, electrical, etc., and concludes that the software industry, which also has the concept of “architecture”, also needs a variety of views to clarify the design intention.

An overview of the

4+1, as the name implies, is to prepare 4 different perspectives and 1 scenario for different stakeholders to articulate the design intentions of the architecture in order to reduce the cost of awareness and communication. Let’s look at the four so-called views: “Logical view,” “Implementation view,” “physical view,” and “process view.”

The above outline is the most abstract 4+1 rendering. For each view, we need to include the following:

  • Define concepts such as components, connectors, containers, and so on for the system
  • Enhance expressiveness with appropriate styles, types, and patterns for each view
  • Consider the constraints in each view
  • Think globally about the relationship between each view

Of course, in reality you don’t necessarily have that many stakeholders to report to; The system is not necessarily complex enough to require multiple perspectives to fully clarify the business scenario. Don’t get caught up in overdesigning at the beginning; Keep the view “editable” and gradually improve the architectural design as the solution matures; Maintain views as you would code. So, in practice, we usually use the old fashioned UML to draw these views.

Logical View

OK, with the abstract concepts out of the way, let’s move on to the specifics of several views.

A logical view is a software element created by a developer that illustrates how the system is broken down into specific functional areas. In object-oriented design languages, this view is known as a class diagram or package diagram. We draw elements like interfaces, classes, packages, and the relationships between them — inheritance, associations, dependencies, and so on. Isn’t DDD all the rage these days? Its bounding context is also the domain of the logical view.

Implementation View

The implementation view is the output of the component compilation system. It consists primarily of packaged modules and components. So what are modules and components here? Take the Java world as an example:

  • A module is a Jar file, a business submodule implemented by one or more developers
  • A component is either a War file or an executable Jar file, and is a combination of modules

The development view draws the dependencies between these modules and the composition between components and modules; A model diagram or subsystem diagram of the system I/O relationship is usually used to describe the details.

Process View

The process view is used to describe the dynamic characteristics of the system at runtime: each element is a process, and the relationships between processes represent the communication between processes. The components in the process view are the actual executables that make up the system runtime, such as:

  • A SPA application that can be run in the browser
  • Linux daemons
  • The SQL script that the database runs

The purpose of the process view is to enable us to think more deeply about system performance metrics such as concurrency, distribution, integration, and fault tolerance by capturing the flow of information exchanged between processes (such as REST API calls, messaging on the bus) and the order and timing of these interprocess communications.

Physical View

The physical view describes how processes map to machines, that is, the topological relationships of software components at the physical level. Elements in this view consist of physical or virtual machines and processes; The relationships between machines represent networks. The physical view is called a deployment diagram in MUL.

We are probably using cloud services more now, and the early UML deployment diagrams are not vivid enough. So, without getting too dogmatic, the key to drawing the physical View is to map out which nodes host the processes shown from the Process View to help us understand system performance and network capacity.

Scenario

In addition to the above four views, let’s explain 1 in 4+1 — scene; It’s responsible for cascading all the views together. Each scenario is used to describe how multiple architectural elements in the view work together. The UML equivalent of “scenario” is use Case; In addition, scenes can also be described in text, which is called a use story. Architects often use scenarios to analyze a particular view, or to depict how different views interact with each other. The final effect is that stakeholders fully understand how the logic, process, implementation, physical components are associated and contribute to the results.

summary

The 4+1 view is the best practice in development to explain the application architecture, each view describing an important aspect of the architecture, and finally connecting these views through scenarios.

Good architecture design can greatly reduce the cost of awareness and communication in software development and maintenance. Ironically, after the 4+1 view was introduced in 1995, most software professionals didn’t draw it. I think the possible reason is that in our time, “software quality” is not the key to product success, and it is not as profitable as we think. At this level of analysis, it may be very desperate; But as practitioners, we actually have a hard time keeping track of what’s really “the key to success.” The only thing we can do is “make our work less horrible.”

The most valuable thing about people is that they still love life after seeing through its essence. — Romain Rolland