In-depth understanding of SpringBoot’s overall architecture design concepts and goals

Source code reading tool

Readers can choose familiar code reading tools based on their daily habits, such as Intellij IDEA, Spring Tool Suite, Eclipse, MyEclipse, etc.

Before reading the Spring Boot source code, we need to build a basic reading environment. Spring Boot has certain requirements for JDK and build tools, such as JDK 8, Maven 3.3, Gradle 5.x and other environments, as long as the corresponding requirements are met.

In order to achieve better learning results, it is recommended that you use the instance debug mode for learning. Therefore, the source code reading tool should preferably support the writing, running, debugging and other functions of the instance.

This article uses Itellj IDEA (IDEA for short) as a code reading tool, and adopts two modes of pure source code reading and instance debugging for learning.

Among them, the pure source code reading mode can help us better comment, write, unit test and other operations of the code, while the instance debug mode can allow us to better understand the running process of the entire project and the specific use of functions. Figure 1-2 and Figure 1-3 show the two modes of reading code through IDEA.

Spring Boot’s planning concepts and policies

We all know that one of the powerful features of Spring is its ability to integrate various open source software. However, with the rapid development of the Internet, various structures emerge one after another, which puts forward new requirements for the flexibility, scalability, scalability, and high availability of the system architecture. As the project develops, Spring slowly integrates more open source software and introduces many configuration files, which leads to high program error rates and low operating efficiency. To handle these situations, Spring Boot came into being.

Spring Boot itself does not provide Spring’s core functions, but serves as Spring’s scaffolding structure to achieve the purpose of quickly building projects, preconfiguring third-party devices, and using them out of the box.

planning concept

Convention Over Configuration, also known as programming by convention, is a software design paradigm designed to reduce the number of decisions software developers need to make and make it simple and flexible to implement. Spring Boot’s central design follows this paradigm perfectly.

Spring Boot’s functions are developed based on “promise over device” from details to the whole. From the creation of infrastructure, configuration files, integration of middleware, built-in containers and various Starters in its ecosystem, everything follows this design paradigm. Starter

As one of the core functions of Spring Boot, it provides automatic configuration modules and dependencies based on automatic configuration code, making software integration simple and easy to use. At the same time, Spring Boot is also encouraging all software organizations to create their own Starter.

planning policy

When it comes to the planning policy of Spring Boot, it is worth mentioning the Pivotal company, the development team of Spring Boot. Pivotal’s corporate goal is to transform how the world builds software. Pivotal provides cloud native application development PaaS platforms and services to enterprise customers, and uses agile software development methodologies to help enterprise customers develop software. This will then improve the work efficiency of software developers, reduce software operation and maintenance costs, realize corporate digital transformation and IT innovation, and help corporate customers ultimately achieve business innovation.

The design philosophy of the Spring Boot architecture perfectly follows the policies of the company to which it belongs. Spring Boot does not provide new solutions to solved problems, but brings a new experience to platforms and developers: integrating mature technology structures, shielding system complexity, simplifying the use of existing technologies, and thereby reducing software complexity. Use] threshold to improve the efficiency of software development and operation and maintenance.

The overall architecture of Spring Boot

In Section 1.2, the core project structure and functions of Spring Boot have been introduced accordingly. In this section, we will learn about the dependencies between different modules of Spring Boot from the architectural level, as shown in Figure 1-4.

In the above figure, in order to express the relationship between Spring Boot projects more clearly, we have omitted some dependency relationships based on the transitivity of dependencies. For example, Spring Boot Starters not only relies on the Spring Boot Autoconfigure project, but also relies on Spring Boot and Spring, and the SpringBoot Autoconfigure project relies on Spring Boot, and Spring Boot relies on Spring-related projects. Therefore, the relationship between Spring Boot Starters and underlying dependencies is omitted from the figure.

Spring Boot Parent is Spring Boot and the Parent project in the figure relies on the Spring Boot project. Similarly, for the sake of clear structure, the relevant dependencies are not shown in the figure.

From Figure 1-4 we can clearly see that Spring Boot is almost completely based on Spring, and provides two core modules, Spring Boot and Spring Boot Autoconfigure, and other related functions are opened based on these two core modules. . The source code analysis related to this article also revolves around two central modules.