Learn Spring Boot - Core Concepts & Key Architecture

#Introduction

In episode 1 you learned why Spring Boot exists. Now we go one level deeper: how it works. Episode 2 dissects the core concepts and key architecture — from the moment the main method is called until your first request is served.

Understanding this architecture matters because all of Spring Boot's behavior can be explained through the concepts we'll cover: beans, the application context, auto-configuration, and request handling. After this episode, you'll not only know how to write code, but also understand what's happening behind the scenes.

#Application Structure and Lifecycle

#The Role of @SpringBootApplication

Every Spring Boot application starts from one main class annotated with @SpringBootApplication. This single annotation is actually a combination of three other annotations:

• @SpringBootConfiguration — marks the class as a configuration source.
• @EnableAutoConfiguration — enables the auto-configuration mechanism.
• @ComponentScan — scans the package and sub-packages to find beans.

@SpringBootApplication
public class BelajarSpringBootApplication {
 
    public static void main(String[] args) {
        SpringApplication.run(BelajarSpringBootApplication.class, args);
    }
}

The SpringApplication.run call in the main method starts the entire lifecycle: creating the ApplicationContext, running auto-configuration, starting the embedded server, and finally printing the log Started BelajarSpringBootApplication.

#Bootstrap and Embedded Server

Once the context is created, Spring Boot runs auto-configuration, processes startup events, and finally starts the embedded server — Tomcat by default — on port 8080. Because the server is part of the application, there's no separate deployment process; the application and the server are one unit.

#The Auto-Configuration Mechanism

#Conditional Beans

The secret of auto-configuration lies in conditional beans. Spring Boot contains hundreds of configuration classes that only activate when certain conditions are met — for example, a library is on the classpath, or a property hasn't been set by the developer. Annotations such as @ConditionalOnClass and @ConditionalOnProperty control this.

# spring-boot-autoconfigure internal logic (condensed)
@ConditionalOnClass({ DataSource.class, JdbcTemplate.class })
@ConditionalOnMissingBean(type = "io.r2dbc.spi.ConnectionFactory")
public class DataSourceAutoConfiguration {
    // builds the DataSource from application.properties
}

This logic means: if you add spring-boot-starter-data-jpa and H2 to the classpath, Spring Boot automatically creates a DataSource for H2 — without a single line of configuration. You only override it if you need to.

#The Convention over Configuration Principle

The convention over configuration principle lets Spring Boot enforce sensible defaults, so you only write configuration for things that genuinely differ from the defaults. This is why small projects can run with an almost empty configuration file.

#Bean Container and Application Context

#ApplicationContext: The Home of All Beans

ApplicationContext is the container that holds all beans and manages their lifecycle. When the application starts, Spring scans the classpath, finds annotations such as @Component, @Service, @Repository, and @Controller, then creates instances and wires up their dependencies.

Dependency Injection happens here. You never write new for beans; you simply declare dependencies in the constructor, and Spring injects them automatically. The full details are in episode 4.

#Request Handling with DispatcherServlet

When an HTTP request comes in, who handles it? The answer: DispatcherServlet — a single central servlet that serves as the gateway for the entire Spring MVC web flow.

• HandlerMapping matches the request URL to a controller method.
• HandlerAdapter invokes that method, passing already-resolved parameters.
• HandlerInterceptor (if any) inserts logic before and after the method.
• The result is converted to a ResponseEntity or model-view, then sent back as a response.

curl http://localhost:8080/api/items

The curl http://localhost:8080/api/items command tests this flow. The DispatcherServlet -> Controller -> Service -> Repository flow is something you'll actually build starting in episode 5.

#Layers, Models, and Application Profiles

#Architectural Layer Separation

A healthy Spring Boot application separates responsibilities into layers:

• Controller — receives HTTP requests and translates them.
• Service — holds the business logic.
• Repository — communicates with the database.
• Model / Entity — data representation in object form.

This separation makes the application easy to test and maintain. Each layer depends on an abstraction (interface), not a concrete implementation.

#Application Profiles and Environment Properties

Real applications run in many environments: local, staging, production. Spring Boot provides profiles to distinguish configuration between environments. You activate a profile with the spring.profiles.active property:

spring.profiles.active=dev
spring.datasource.url=jdbc:h2:mem:testdb
spring.jpa.hibernate.ddl-auto=create-drop

With profiles, you can use H2 locally and PostgreSQL in production without changing code — only configuration. We'll go deeper into this concept in episode 8.

#Closing

Episode 2 gave you a mental map of Spring Boot's architecture: the lifecycle starting from SpringApplication.run, the auto-configuration mechanism with conditional beans, the application context as the home of all beans, DispatcherServlet as the gateway for requests, and the separation into layers and application profiles.

Key takeaways:

• @SpringBootApplication combines configuration, component scan, and auto-configuration.
• Auto-configuration uses conditional beans: active only when the classpath conditions are met.
• ApplicationContext manages all beans and dependency injection.
• DispatcherServlet maps HTTP requests to controllers via HandlerMapping.
• The controller, service, repository, and model layers keep the application well structured.
• Application profiles separate configuration between environments without changing code.

In the next episode, episode 3, we'll start our first application — creating a project via Spring Initializr, navigating the standard directory structure, running the application with embedded Tomcat, and managing basic configuration in application.properties. Let's move from theory to practice.