Spring Boot The Framework
In this blog, we will explore a little about the Spring Boot framework. We will discuss the structure and architecture of the Spring Boot framework and the Spring Boot workflow architecture.
Spring Boot uses the hierarchical architecture where each of the layers is stacked on top of each other and communicate is also in the same fashion.
Spring Boot Architecture
Now let’s explore the main layers and architecture of Spring Boot to understand the inner working of the framework. The layers a divided into 4 main categories:
Presentation Layer
Business Layer
Persistence Layer
Database Layer
Nevertheless, soon you will discover that the business layer is the most important layer for a backend engineer as it is where all the logic of your application is written. Now let's explore each of these layers and learn what function they provide.
Presentation Layer
The presentation layer is what the user sees from the outside or what is exposed to the outside world. It can be a JSON structure that is made up of viewpoints. It can be split into the front layer which is what is seen from the outside and a back layer which is where the structure is built from viewpoints. The back layer also interprets JSON and handles authentication and HTTP requests before entering into the business layer.
Business Layer
The business layer houses all the logic that is specific to the application under development. It interacts with both the presentational layer and the persistence to perform its responsibilities. It is responsible for performing validations, performing authorization, and handling business logic and rules and it consists of service classes.
Persistence Layer
The persistence layer is responsible for all the storage logic including databases and any other form of data persistence. It is responsible for containing storage logic, Fetching objects, and translating them into database rows (and vice versa).
This layer is the equivalent of the Repository interface and database queries are written inside this interface. The Persistence layer is the only layer that communicates with the Business layer and the Database layer.
Database Layer
The database layer contains all the databases such as MySQL, MongoDB, Postgres, etc as the name suggests. It is responsible for performing database operations (mainly CRUD operations) and it is the actual database that you decide to use to build your application.
Spring Boot Workflow
There’s no doubt that Spring Boot relies heavily on the Spring framework, which means that it integrates almost all of the features and modules of Spring such as Spring MVC, Spring Core, etc.
Therefore, the Spring Boot framework is structured using the popular MVC (Model, View, Controller) pattern that is slightly modified.
Here is a theoretical example of the workflow of Spring Boot from Request to Response:
First, the Client makes an HTTP request using GET, PUT, POST, etc.
The Controller class receives the HTTP request.
The Controller understands what type of request will process, and then it deals with it.
If it is needed, it calls the Service class.
The Service Class is going to handle the business logic. It does this on the data from the database.
If everything goes well, it returns a response as a JSP page.
Modified MVC Architecture
When you are building a Spring Boot Web API project, typically, you will want your code to be maintainable, modular, and have a separation of concerns. Therefore, the 4 main layers above are further broken down into different smaller components which make up the modified MVC pattern used in Spring Boot.
Below are some of the components that make up the Spring Boot framework and you will encounter these components always as you continue to work with the framework.
Controllers: Controllers handle incoming HTTP requests and return the appropriate responses. It receives requests from clients, invokes validations and business logic using Services, and returns the response to the client. Controller classes are usually annotated with @RestController or @Controller annotations and also have methods that are annotated with request mapping annotations like @RequestMapping, @GetMapping, @PostMapping, and so on.
Services: Services house the business logic of your application. This is where you write all the complex business rules, and coordinate data access, and transformation operations. They process data, perform validations, apply business rules, and invoke data access operations through repositories or DAOs(Data Access Objects). The service class is an abstraction layer between the controller and the data access layer.
Data Access: Data Access interacts with the underlying data storage systems, such as databases or external Web APIs. It carries out CRUD (Create, Read, Update, Delete) operations on data. It consists of repositories or DAOs (Data Access Objects) that provide an abstraction for database operations. Spring Boot provides support for data access and manipulation through libraries like Spring Data JPA.
Models: Models contain the entities or domain objects that represent the data and the relationships between them. These domain objects are mapped to database tables. Models provide a definition for the structure and behavior of the data used in the application. It may also include DTOs (Data Transfer Objects) and/or View Models for transferring data between layers or to external clients.
Exception Handling: Exception handling deals with capturing and handling exceptions that occur during the execution of the API. It provides a mechanism to catch exceptions, transform them into meaningful error responses, and return them to the client. Spring Boot offers various exception-handling techniques, such as using @ExceptionHandler annotations or implementing custom exception handlers.
Configurations: Configurations contain configuration files and classes required for setting up the Spring Boot web API. It contains properties files (application.properties or application.yml) which are used for configuring various aspects of the application, as well as custom configuration classes that define beans, security settings, or other application-specific configurations.
Spring Boot Architecture Patterns
Spring Boot applications often follow certain architectural patterns to achieve modularity, scalability, and maintainability. Here are some common architectural patterns used in Spring Boot development:
MVC (Model-View-Controller):
Spring Boot follows the MVC pattern for building web applications.
Model: Represents the application’s data and business logic.
View: Responsible for rendering the user interface.
Controller: Handles user requests, interacts with the model, and updates the view.
Microservices Architecture:
Spring Boot is commonly used in microservices architectures where the application is decomposed into small, independently deployable services.
Each microservice is responsible for a specific business capability and communicates with other services through APIs.
Restful API Design:
Spring Boot promotes the design of RESTful APIs for communication between components.
Controllers expose RESTful endpoints, and data is typically exchanged in JSON format.
Layered Architecture:
Organising the application into layers like presentation, service, repository, and entity helps maintain a separation of concerns.
This layered architecture promotes modularity and testability.
Dependency Injection (DI) / Inversion of Control (IoC):
Spring Boot relies heavily on the principle of dependency injection, where dependencies are injected into components rather than being created by the components themselves.
This reduces tight coupling and makes the application more maintainable.
Event-Driven Architecture:
Spring Boot supports event-driven architecture through the use of Spring Events.
Components can publish and subscribe to events, allowing for loosely coupled communication between different parts of the application.
CQRS (Command Query Responsibility Segregation):
CQRS separates read and write operations, allowing for independent scaling of the query (read) and command (write) sides.
Spring Boot can be used to implement CQRS patterns using different components for command and query responsibilities.
Saga Pattern:
In microservices architectures, the saga pattern is often used to manage distributed transactions.
Spring Boot applications can implement sagas by coordinating a series of transactions across multiple microservices.
Gateway Pattern:
API gateways are used to manage and route requests in microservices architectures.
Spring Cloud provides tools like Spring Cloud Gateway for building API gateways.
These patterns can be combined and adapted based on the specific requirements of the application. The flexibility of Spring Boot allows developers to choose and implement the patterns that best suit their needs.
Architecture of Spring Boot Microservices
The architecture of Spring Boot microservices typically follows principles that align with the characteristics of microservices, such as modularity, independence, and distributed systems. Here’s a conceptual overview of the architecture for a Spring Boot microservices application:
Microservices:
The application is decomposed into small, independent, and loosely coupled services, each focused on a specific business capability.
Microservices communicate with each other through well-defined APIs, often exposed as RESTful endpoints.
Service Registry and Discovery:
Services register themselves with a service registry (e.g., Spring Cloud Netflix Eureka).
Service discovery allows services to locate and communicate with each other dynamically.
API Gateway:
An API Gateway (e.g., Spring Cloud Gateway, Netflix Zuul) is used to manage and route external requests to the appropriate microservices.
It can handle authentication, load balancing, and routing.
Configuration Management:
Centralised configuration management (e.g., Spring Cloud Config) allows microservices to retrieve configuration properties dynamically.
Configuration can be stored in a version-controlled repository and updated without redeploying services.
Distributed Data Management:
Microservices often have their own databases, and the choice of database depends on the specific requirements of each service.
Eventual consistency and distributed data management strategies may be employed.
Event-Driven Architecture:
Events and messaging systems (e.g., Spring Cloud Stream, Apache Kafka) are used for communication between microservices.
Event-driven architecture supports loose coupling and scalability.
Polyglot Architecture:
Each microservice can be implemented in a different programming language or use a different technology stack, known as a polyglot architecture.
The choice of technology is based on the specific requirements of each service.
Testing and Continuous Integration/Continuous Deployment (CI/CD):
Microservices are independently testable, allowing for easier unit testing and integration testing.
CI/CD pipelines enable automated testing and deployment of microservices.
Domain-Driven Design (DDD):
- Microservices are often designed based on domain-driven design principles, emphasising a clear understanding of the business domain and its interactions.
This architecture allows for flexibility, scalability, and easy maintenance of a microservices-based system. Spring Cloud provides a set of tools and libraries to implement many of these patterns and streamline the development of microservices in a Spring Boot environment.