Spring Framework, Spring Core і Spring Boot

1. Один «Spring» і так багато значень

Проблема тут дуже проста: назва одна, а рівнів розмови — кілька. Іноді під Spring мають на увазі сам Spring Framework. Іноді — лише контейнер і DI. Іноді — Spring Boot. А іноді — взагалі всю екосистему разом із Data, Security, Cloud та іншими проєктами. Формально все це «про Spring», але з інженерного погляду це різні речі.

Для новачка це дуже схоже на ситуацію, коли словом «автомобіль» одночасно називають двигун, коробку передач, заводську комплектацію і всю автомобільну індустрію. Це не зовсім неправда. Але користі від такого формулювання мало. Щойно з’являються реальні запитання — «хто створює об’єкти?», «хто підняв web-середовище виконання?», «хто дав ці дефолти?» — усе змішується і перестає бути зрозумілим.

У бекенд-розробці це особливо відчутно, тому що одна й та сама кодова база справді використовує кілька Spring-шарів одночасно. Ви можете писати звичайний Java-клас предметної області, жити всередині Spring-контексту, користуватися модулем Spring MVC і запускати все це через Spring Boot. В одному проєкті можуть перетинатися кілька рівнів — і це нормально. Ненормально лише не розрізняти їх.

Гарна новина: карта понять тут доволі компактна. Я не буду розповідати вам роман про всю Spring-екосистему. Достатньо побачити чотири опорні шари: звичайний Java-код, Spring Core, Spring Framework і Spring Boot. Після цього і сусідні проєкти на кшталт Data чи Security теж починають знаходити своє місце.

2. Звичайний Java-код нікуди не зникає

Дуже важливо почати не зі Spring, а зі звичайного Java-коду. Одна з найшкідливіших ілюзій новачка звучить так: «Якщо проєкт на Spring, значить майже весь код у ньому має бути “кодом про Spring”». Ні. Гарний проєкт на Spring і далі складається з великої кількості звичайного Java-коду — предметних класів, сервісних методів, об’єктів-значень, перетворень даних, правил домену.

Наприклад, картка курсу взагалі не зобов’язана знати, що в проєкті є Spring:

public class CourseCard { // Звичайний доменний клас: без анотацій Spring і магії контейнера

    private final String slug; // Ідентифікатор/частина URL (просто дані предметної області)
    private final String title; // Заголовок курсу (також просто дані)
    private final boolean published; // Прапорець публікації (бізнес-стан об’єкта)

    public CourseCard(String slug, String title, boolean published) { // Конструктор сам приймає всі потрібні значення
        this.slug = slug; // Зберігаємо поля: жодних залежностей від Spring-контексту
        this.title = title;
        this.published = published;
    }

    public String displayTitle() { // Поведінка об’єкта: формування рядка для відображення
        return title + " (" + slug + ")"; // Уся логіка локальна й придатна до тестування без Spring
    }

    public boolean isPublished() { // Геттер стану (частина предметної моделі)
        return published;
    }
}

Цей код нудний — і це комплімент. Він не займається платформою, не думає про стартери, не сперечається з конфігурацією. Він просто виражає маленький шматок предметної логіки. Саме такі класи і мають становити основу проєкту.

Spring не замінює Java-код предметної області. Spring допомагає цьому коду жити всередині застосунку як системи.

Коли це правило засвоєно, зникає важливий страх. Вам не потрібно писати «мовою Spring» усе підряд. Потрібно вміти відрізняти звичайний код застосунку від платформених механізмів навколо нього 👌

3. Spring Core: збирає об’єкти й тримає їх разом 🧲

Spring Core — це фундамент, на якому будується вся подальша історія. Якщо говорити зовсім по-людськи, Core відповідає за те, щоб об’єкти застосунку створювалися, пов’язувалися і жили не хаотично, а всередині керованого контейнера.

У маленькому Java-проєкті можна цілком чесно збирати все вручну:

public class DemoApp { // Найпростіший застосунок без Spring: усе збираємо вручну

    public static void main(String[] args) { // Точка входу звичайної Java-програми
        CourseCard card = new CourseCard("spring-boot", "Spring Boot", true); // Явний new: ми самі керуємо створенням об’єкта
        System.out.println(card.displayTitle()); // Прямий виклик методу й виведення результату: жодного контейнера
    }
}

Поки об’єктів мало, ручне складання здається безпечним. Але щойно у вас з’являються сервіси, конфігурація, web-шар, інфраструктурні компоненти і залежності між ними, складання застосунку починає жити своїм окремим життям. Хто кого створює? Де зберігається спільний об’єкт конфігурації? Хто має жити один раз, а хто створюється під задачу? Хто має коректно завершитися під час зупинки застосунку? Ось тут і починається територія Spring Core 🔧

Core дає контейнер об’єктів і модель керування ними. На початковому етапі цього достатньо. Не потрібно поки що занурюватися в детальну розмову про IoC/DI. Корисно побачити саму ідею: застосунок — це не набір випадкових new, розкиданих по коду. Це граф об’єктів, яким керує контейнер 🧠

І щойно ви чуєте слова ApplicationContext, bean, інʼєкція залежностей — це вже дуже близько до Spring Core. Саме тут лежить фундамент, без якого Boot далі справді сприйматиметься як магія.

4. Spring Framework: модулі та можливості навколо фундаменту

Spring Framework — це ширший шар. Якщо Core відповідає на запитання «хто збирає й тримає об’єкти застосунку», то Framework відповідає на запитання «які можливості взагалі є навколо цього фундаменту». Саме тут живуть веб-механіки, контекст застосунку, події, конфігураційні можливості та інші будівельні блоки.

Тобто Framework — це не «інший конкурент Core». Core — його серце, а Framework — ширший набір модулів і механізмів навколо нього. Коли кажуть, що Spring уміє веб, валідацію, події або різні інфраструктурні інтеграції, йдеться зазвичай про можливості на рівні Framework і його модулів.

Корисно тримати в голові таку просту схему 🤔

Core — про життя об’єктів.

Framework — про можливості застосунку, які будуються навколо цього життя.

Це знімає багато плутанини. Наприклад, якщо ви бачите веб-поведінку застосунку, це не означає, що Boot вигадав HTTP. Ні. Boot уміє зручно зібрати й запустити цю поведінку, але самі можливості приходять зі світу Spring глибше і ширше.

На цьому місці стає простіше зрозуміти і сусідні проєкти. Spring Data, Spring Security та інші речі — не «частини Boot» у прямому сенсі. Це окремі проєкти тієї самої екосистеми, які теж спираються на фундамент Spring і часто прекрасно живуть у Boot-застосунках 🔌

5. Spring Boot перетворює все це на зручний старт

Тепер можна поставити Boot на правильне місце. Spring Boot — це не заміна Spring Framework і не «полегшений Spring». Це платформений шар поверх Spring, який збирає робочу базу застосунку: старт, дефолти, узгодження залежностей, автоконфігурацію, зручну модель запуску і конфігурації.

Саме тому Boot так сильно відчувається в житті кожного розробника. Його внесок дуже помітний: короткий main(), зрозумілий старт, вбудований сервер, дефолтна конфігураційна модель, кероване середовище виконання. Але важливо не плутати помітність із глибиною. Boot — не весь Spring. Він будується поверх того самого фундаменту.

Spring Boot — це шар, який перетворює можливості Spring на зручно стартований застосунок.

Візьмемо знову знайому точку входу:

import org.springframework.boot.SpringApplication; 
import org.springframework.boot.autoconfigure.SpringBootApplication; 

@SpringBootApplication // Повідомляємо Boot: це головна конфігурація застосунку, від неї будується середовище виконання
public class CatalogServiceApplication { // Клас-точка входу (часто збігається з коренем пакетів)

    public static void main(String[] args) { // Звичайний Java main, але тепер він делегує запуск Boot
        SpringApplication.run(CatalogServiceApplication.class, args); // Старт: створюється ApplicationContext і запускається весь життєвий цикл
    }
}

Коли ви бачите такий код, не потрібно думати: «О, це і є весь Spring». Правильніше думати інакше: «Це Boot запускає застосунок, який спирається на Spring-фундамент і його можливості».

Ця думка дуже тверезить. Вона дає змогу не сперечатися щоразу, «чия це фіча», а розуміти рівень відповідальності.

6. Одна карта на всю тему

Нижче — таблиця, яку корисно тримати в голові весь курс. Вона не замінює деталей, але дуже добре тримає орієнтир:

Ця карта корисна не лише для запам’ятовування термінів. Вона захищає вас одразу від двох частих помилок.

Перша помилка — приписувати Boot те, що належить до глибшого Spring-фундаменту. Друга — вважати, що все «справжнє» відбувається лише в Core, а Boot — це просто косметика. На практиці Boot — дуже важливий платформений шар, просто в нього інша роль: не вигадувати фундамент заново, а збирати його в зручний робочий застосунок.

Java-код виражає предметну логіку. Spring Core керує об’єктами. Spring Framework дає можливості. Spring Boot збирає все це в зрозуміле середовище виконання.

7. Як ця карта допомагає саме в нашому курсі

Тепер легше зрозуміти, що саме ви зараз вивчатимете. Курс із Spring Boot не намагається замінити окремий глибокий курс із Spring Core і не розповзається в огляд усієї Spring-екосистеми. Його завдання вже видно з карти шарів: навчити вас бачити й використовувати платформений шар Boot без відчуття чорної скриньки.

Якщо ви вже проходили окремий Spring Core, це дасть додаткову глибину. Якщо ні — це не катастрофа. Але мінімальне розуміння контейнера і DI все одно знадобиться, тому що інакше слова ApplicationContext, bean і контекст запуску залишаться набором магічних термінів.

Саме тому курс із Boot залишається самостійним, але не вдає, ніби фундамент Core можна спокійно ігнорувати. Щойно ви бачите, що Boot підіймає ApplicationContext, запитання виникає само собою: а хто взагалі живе всередині цього контексту і як об’єкти виявляються пов’язаними? Ось тут уже починається той шар Spring, без якого магію потрібно перетворювати на механіку 🔍

Ця думка нам ще дуже знадобиться. Поки що достатньо впевнено розрізняти ролі. Коли ролі не змішані, уся екосистема Spring починає виглядати набагато спокійніше.

8. Типові помилки 😅

Помилка №1: використовувати Spring Framework, Spring Core і Spring Boot як синоніми.
Це найчастіша плутанина на старті. Здається, що раз усе називається Spring, то й розрізняти нічого. На практиці без розрізнення шарів майже неможливо зрозуміти, хто за що відповідає і чому застосунок поводиться саме так.

Помилка №2: думати, що під час використання Spring предметний Java-код «зникає».
Гарний проєкт на Spring і далі складається з великої кількості звичайного Java-коду. Spring потрібен не для того, щоб замінити доменну логіку, а для того, щоб дати їй середовище життя всередині застосунку.

Помилка №3: вважати Spring Boot окремим світом, не пов’язаним зі Spring Framework.
Boot не живе сам по собі. Він будується поверх Spring-фундаменту і використовує його механізми. Якщо подумки відрізати Boot від Framework і Core, далі все почне виглядати як випадковий набір зручних прийомів без внутрішньої логіки.

Помилка №4: недооцінювати роль Spring Core, тому що «Boot і так усе запускає».
Boot справді дає зручний старт. Але щойно ви захочете розуміти, що відбувається всередині застосунку, запитання про контейнер і DI все одно постане. Комфортний старт не скасовує потреби бачити фундамент.

Помилка №5: ставитися до карти шарів як до формальної класифікації.
Ця карта потрібна не заради екзаменаційного визначення. Вона потрібна як робоча навігація. Коли ви далі зустрінете стартери, конфігурацію, автоконфігурацію, web-основу та механізми запуску, вам буде набагато легше розуміти, на якому рівні розмови ви взагалі перебуваєте.