Spring Ecosystem vs Framework vs Boot

The Architectural Question

Treating every Spring capability as “Boot magic” makes dependency, context, MVC, Data, Security, and Cloud failures impossible to localize.

What this guide proves

Spring Portfolio
Spring Framework
Spring Boot

The mental model

Spring is the name of the portfolio, not one runtime. The portfolio ships projects with separate jobs: Framework supplies the container and programming model, Data supplies repository abstractions, Security supplies authentication and authorization integration, Cloud supplies distributed-system patterns, and Boot assembles common combinations. See the full list in the Spring project index.

Spring Framework is the layer you always run on inside a Boot app. When a class becomes a bean, a dependency is injected, a transaction proxy wraps a service, an MVC controller answers a request, or an event is published, that behavior comes from the Framework, as documented in the Spring Framework 6.2 Reference.

Spring Boot is the assembly layer. It pins compatible dependency versions, hands you starter dependencies, evaluates conditional auto-configuration, starts an embedded runtime, reads external configuration, exposes Actuator, and packages the app as a runnable artifact. The Spring Boot 3.5 Reference describes each piece.

Debug by ownership. A missing bean means checking component scanning and the Framework container. A default MVC, Jackson, or Tomcat bean that appears or backs off means checking Boot auto-configuration. A repository method that misbehaves means checking Spring Data and the persistence provider, not blaming Boot.

The Bill of Materials (BOM) pattern: Spring Boot ships `spring-boot-dependencies`, a curated BOM that pins compatible versions for over 200 external libraries including Jackson, Hibernate Validator, Netty, Flyway, and Micrometer. Declaring explicit version tags on dependencies managed by the BOM bypasses tested compatibility and is the leading cause of binary incompatibility and `NoSuchMethodError` exceptions at runtime.

Modern Spring Boot 3.5 on Java 21 additions: Boot natively embraces Java 21 Virtual Threads via `spring.threads.virtual.enabled=true`, introduces first-class Docker Compose lifecycle management (`spring-boot-docker-compose`) for local infrastructure, and supports declarative HTTP client interfaces via `@HttpExchange`.

Runtime Architecture & Flow

Spring portfolio · Clear boundaries

Spring is the ecosystem; Framework is the foundation; Boot is the assembly layer

Spring Boot does not replace Spring Framework. A Boot application uses the Framework container, beans, transactions, MVC, validation, and testing APIs, then adds opinionated dependency management, auto-configuration, embedded runtime packaging, externalized configuration, and production conventions.

01Spring portfolio
02Spring Framework
03Spring Boot
04Starters
05BOM dependency management
06Auto-configuration
07Embedded runtime
08Virtual Threads

Layer	What it provides	Important boundary
Spring portfolio	A family of projects: Framework, Boot, Data, Security, Batch, Integration, Cloud, and more.	An ecosystem name, not one dependency or runtime.
Spring Framework	IoC, DI, AOP, transactions, events, validation, testing, MVC, WebFlux, JDBC, and integration foundations.	Does not choose and configure a complete application stack for you.
Spring Boot	Dependency management, starters, conditional defaults, executable packaging, external config, Actuator, and operational conventions.	Does not replace Framework; Boot applications run on Framework APIs and containers.
Data / Security / Cloud	Independent projects for persistence abstractions, security, and distributed-system patterns.	Not features inside Boot; Boot configures integrations when those libraries are present.

Working Implementation

Runnable snippet path

Predict, run, and change each example

4 focused examples

The mental model

Spring is the name of the portfolio, not one runtime. The portfolio ships projects with separate jobs: Framework supplies the container and programming model, Data supplies repository abstractions, Security supplies authentication and authorization integration, Cloud supplies distributed-system patterns, and Boot assembles common combinations. See the full list in the Spring project index.

Spring Framework is the layer you always run on inside a Boot app. When a class becomes a bean, a dependency is injected, a transaction proxy wraps a service, an MVC controller answers a request, or an event is published, that behavior comes from the Framework, as documented in the Spring Framework 6.2 Reference.

Spring Boot is the assembly layer. It pins compatible dependency versions, hands you starter dependencies, evaluates conditional auto-configuration, starts an embedded runtime, reads external configuration, exposes Actuator, and packages the app as a runnable artifact. The Spring Boot 3.5 Reference describes each piece.

Debug by ownership. A missing bean means checking component scanning and the Framework container. A default MVC, Jackson, or Tomcat bean that appears or backs off means checking Boot auto-configuration. A repository method that misbehaves means checking Spring Data and the persistence provider, not blaming Boot.

The Bill of Materials (BOM) pattern: Spring Boot ships `spring-boot-dependencies`, a curated BOM that pins compatible versions for over 200 external libraries including Jackson, Hibernate Validator, Netty, Flyway, and Micrometer. Declaring explicit version tags on dependencies managed by the BOM bypasses tested compatibility and is the leading cause of binary incompatibility and `NoSuchMethodError` exceptions at runtime.

Modern Spring Boot 3.5 on Java 21 additions: Boot natively embraces Java 21 Virtual Threads via `spring.threads.virtual.enabled=true`, introduces first-class Docker Compose lifecycle management (`spring-boot-docker-compose`) for local infrastructure, and supports declarative HTTP client interfaces via `@HttpExchange`.

01

Spring Framework: construct an application context explicitly

This is Spring without Boot. The Framework scans components and performs dependency injection, but application assembly and runtime choices remain yours.

FrameworkApplication.javajava

@Configuration
@ComponentScan("com.acme.catalog")
class FrameworkConfiguration {}

public class FrameworkApplication {
    public static void main(String[] args) {
        try (var context = new AnnotationConfigApplicationContext(
                FrameworkConfiguration.class)) {
            var catalog = context.getBean(CatalogService.class);
            catalog.printSummary();
        }
    }
}

Remember

ApplicationContext, component scanning, `@Bean`, and dependency injection belong to Spring Framework.

Change one input, predict the result, then compile or test it before continuing.

02

Spring Boot: assemble a Spring application from one entry point

`@SpringBootApplication` adds Boot auto-configuration to Framework configuration and component scanning. `SpringApplication` prepares the environment and appropriate context.

CatalogApplication.javajava

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

Remember

Your services are still ordinary Spring beans; Boot supplies conditional defaults and application lifecycle conventions.

Change one input, predict the result, then compile or test it before continuing.

03

One starter describes a coherent capability

A starter is primarily a dependency descriptor. Boot dependency management chooses compatible versions; auto-configuration reacts to the resulting classpath.

pom.xmlxml

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<!-- The dependency graph includes Spring MVC, JSON support,
     validation integration, logging, and an embedded servlet server.
     Inspect the exact graph with: ./mvnw dependency:tree -->

Remember

A starter adds libraries; auto-configuration decides which beans to create from classes, properties, and existing beans.

Change one input, predict the result, then compile or test it before continuing.

04

Modern declarative HTTP client interface in Spring Boot 3

Spring Framework 6.2 and Boot 3.5 allow defining type-safe HTTP clients with interfaces rather than procedural RestTemplate / WebClient boilerplate.

OrderClient.javajava

@HttpExchange("/api/v1/orders")
public interface OrderClient {
    @GetExchange("/{id}")
    OrderResponse findById(@PathVariable("id") String id);
}

Remember

Declarative clients belong to Spring Framework 6.2; Boot provides auto-configuration adapters to bind them to RestClient or WebClient.

Change one input, predict the result, then compile or test it before continuing.

Synthesis & Production Verification

Deliberate Failure Condition

Break: Exclude spring-boot-autoconfigure
Observe: No beans found for WebMvc
Repair: Boot provides the defaults; Framework provides the DI container.

Production Acceptance Criteria

Explain the portfolio, Framework, Boot, and adjacent projects separately
Compare explicit Framework assembly with Boot conditional defaults
Identify what Boot adds without claiming it replaces Framework

Architectural & Technical Review

Core Interview Questions

Q01What is the practical difference between Spring Framework and Spring Boot?Show answer

Spring Framework supplies capabilities such as the IoC container, MVC, and transaction management. Spring Boot selects compatible dependencies, starts the application, and contributes conditional defaults around those capabilities without replacing them.

Q02Can Spring Framework be used without Spring Boot?Show answer

Yes. An application can create an ApplicationContext and configure Framework features directly. It then owns the dependency selection, infrastructure configuration, packaging, and operational setup that Boot normally standardizes.

Q03Why does a user-defined bean often replace a Boot default?Show answer

Many Boot defaults are guarded by @ConditionalOnMissingBean. When the application supplies that capability, the condition no longer matches and Boot backs off rather than creating a competing bean.

Production Pitfalls

Critical Anti-Patterns

Pitfall: Attributing every Spring feature to Boot — This sends diagnosis to starters and properties when the actual rule belongs to the Framework container, MVC, transactions, or proxies.
Pitfall: Replacing defaults before identifying their owner — First find the auto-configuration and condition responsible; then choose a property, a narrow bean, or an exclusion proportional to the requirement.

Primary Documentation & Specifications

Lesson Primary References

Spring Framework 6.2 Overview Spring Boot 3.5 Getting Started

Supplementary Module Resources

@SpringBootApplication Structuring Spring Boot code Auto-configuration Externalized configuration