Architecture

Spring Framework is organized as a layered set of Gradle modules. Lower layers are foundation libraries (spring-core, spring-beans); higher layers compose them into the IoC container, AOP, data access, and the two web stacks. Each module is a separately published JAR (org.springframework:spring-<name>), and applications pull in only what they use.

Module dependency overview

graph TD
    core[spring-core]
    beans[spring-beans]
    aop[spring-aop]
    context[spring-context]
    spel[spring-expression]
    aspects[spring-aspects]
    ctxsupport[spring-context-support]
    tx[spring-tx]
    jdbc[spring-jdbc]
    orm[spring-orm]
    oxm[spring-oxm]
    r2dbc[spring-r2dbc]
    web[spring-web]
    mvc[spring-webmvc]
    flux[spring-webflux]
    ws[spring-websocket]
    msg[spring-messaging]
    jms[spring-jms]
    test[spring-test]

    beans --> core
    aop --> beans
    aop --> core
    context --> aop
    context --> beans
    context --> core
    context --> spel
    aspects --> context
    ctxsupport --> context
    tx --> beans
    tx --> core
    tx -.optional.-> aop
    jdbc --> beans
    jdbc --> core
    jdbc --> tx
    orm --> jdbc
    r2dbc --> tx
    web --> beans
    web --> core
    web -.optional.-> oxm
    web -.optional.-> aop
    web -.optional.-> context
    mvc --> aop
    mvc --> beans
    mvc --> context
    mvc --> web
    flux --> beans
    flux --> core
    flux --> web
    ws --> context
    ws --> web
    ws -.optional.-> msg
    ws -.optional.-> mvc
    msg --> beans
    msg --> core
    jms --> msg
    jms --> tx
    test --> core

The arrows represent compile-time api dependencies as declared in each module's *.gradle file. Dotted arrows are optional dependencies — pulled in only when the corresponding feature is used.

Layers from bottom to top

1. Core utilities — spring-core provides Resource, ResourceLoader, Environment, the type system (ResolvableType, MethodParameter), AOT generation infrastructure, and shaded copies of ASM, CGLIB, Objenesis, and JavaPoet. See modules/spring-core.
2. Beans — spring-beans defines BeanDefinition, BeanFactory, the property-binding machinery, and the bean lifecycle. See modules/spring-beans.
3. AOP — spring-aop provides Spring's proxy-based AOP (JDK and CGLIB). spring-aspects adds compile-time AspectJ weaving for transactional, async, and cacheable annotations. See modules/spring-aop.
4. Context — spring-context ties together beans, AOP, SpEL, events, validation, scheduling, JSR-303, and annotation-driven configuration through ApplicationContext. See modules/spring-context.
5. Data access — spring-jdbc, spring-tx, spring-orm, spring-r2dbc, spring-oxm provide JDBC, transaction management, JPA/Hibernate integration, reactive database access, and XML marshalling.
6. Web — spring-web is shared by both stacks. spring-webmvc is the Servlet-based MVC framework; spring-webflux is the reactive (Reactive Streams / Reactor) alternative. spring-websocket and spring-messaging add WebSocket and STOMP support.
7. Test — spring-test provides the TestContext framework, mocks for Servlet/WebFlux, and MockMvc / WebTestClient.

Two web stacks, one foundation

Spring intentionally maintains two parallel web stacks:

Aspect	Spring MVC (spring-webmvc)	Spring WebFlux (spring-webflux)
Programming model	Imperative, blocking	Reactive (Reactor Mono/Flux), non-blocking
Runtime API	Servlet	Reactive Streams; runs on Servlet 5+, Reactor Netty, Undertow
Concurrency	One thread per request	Event loop, fewer threads
Shared types	HttpStatusCode, HttpHeaders, MediaType, HttpMessageConverter (in spring-web)

Both stacks share spring-web for HTTP primitives, message converters, content negotiation, and CORS. They differ in their controller/handler mechanics, view resolution, and runtime adapters. See features/web-mvc and features/reactive-stack.

Cross-cutting concerns

A few capabilities span many modules:

• Annotation-driven configuration — @Configuration, @Bean, @ComponentScan, @Component, @Autowired are processed by ConfigurationClassPostProcessor and friends in spring-context.
• AOT (Ahead-of-Time) processing — Each module contributes RuntimeHints registrars to support GraalVM native images. Code lives under */aot/ packages across modules.
• Reactive support — Reactor types (Mono, Flux) flow through spring-webflux, spring-r2dbc, and reactive spring-messaging adapters.
• Internationalization, validation, conversion — MessageSource, Validator, and ConversionService are wired in spring-context and reused by both web stacks.

Build and packaging

The root build (build.gradle) configures three groups of subprojects:

• moduleProjects — every directory starting with spring- (the published JARs)
• javaProjects — everything except the framework-* BOM/platform/api/docs aggregates
• framework-* projects — Bill of Materials, dependency platform, aggregated Javadoc, reference docs

Each spring-* module applies gradle/spring-module.gradle, which sets up MRJAR support, Kotlin compilation where applicable, nullability checks (io.spring.nullability), and Javadoc with cross-links to JDK 17, Reactor, and JUnit.

What this codebase is not

• Not a runtime. The framework does not bundle a server. Spring Boot adds embedded Tomcat/Netty.
• Not a security framework. Authentication and authorization live in Spring Security.
• Not a data repository abstraction. spring-jdbc provides templates; higher-level repositories live in Spring Data.
• Not opinionated. Spring Boot supplies opinionated defaults; the framework itself is configuration-heavy by design.