Собственный bean вместо default

1. Когда нужен override default

В какой-то момент любой разработчик сталкивается с ощущением: «Boot классный, но вот тут бы я сделал чуть иначе». Это нормальный этап взросления проекта. Сервис уже запускается, у него есть структура, и вы начинаете видеть детали: где хочется другой формат сообщения, другой алгоритм, другой маленький кусочек поведения.

Важно не перепутать два типа желания. Первый — здоровый: «мне нужно поменять одну точку поведения, потому что у нас есть конкретная причина». Второй — опасный: «мне не нравится, что я не понимаю, откуда это взялось, поэтому давайте выключим половину платформы и соберём всё руками». Второй тип обычно приводит к тому, что вы вроде бы «взяли контроль», но на самом деле потеряли преимущества Boot: предсказуемые defaults, совместимость и нормальную поддержку обновлений.

Давайте сразу зафиксируем мысль: самый безопасный способ кастомизации Boot — это не отключение, а замена одного конкретного бина на свой. У Boot для этого есть целая философия: «я настрою по умолчанию, но если вы явно сказали “вот мой вариант” — я отойду в сторону». В англоязычных материалах это часто называют backoff — «отступление назад».

Boot уже умеет сам собирать defaults через auto-configuration. Теперь важно не ломать эту сборку грубой рукой. Удобно держать в голове простую лестницу вмешательства: сначала ищем готовый property или флаг, потом подменяем один конкретный bean, и только если целый блок поведения правда не нужен — думаем про exclusion. А когда приходится открывать auto-config исходники, цель та же: выбрать самый слабый рычаг, а не пересобирать платформу вручную.

2. Default-beans и auto-configuration

Когда вы подключаете стартеры, на classpath появляются библиотеки. А вместе с ними появляются и классы auto-configuration — специальные конфигурации, которые умеют регистрировать инфраструктурные бины. С точки зрения Spring это всё те же `@Configuration`-классы, просто подключаются они не через component scanning, а через механизм auto-configuration.

Представьте, что Spring Boot — это заботливый коллега, который приходит в проект и говорит: «Я вижу, что у вас в зависимостях есть вот это и вот это. Значит, скорее всего вам нужны такие-то технические компоненты. Я могу их создать и настроить “разумно по умолчанию”». Это и есть default-beans: не «обязательная истина», а предложение платформы, которое можно принять или заменить.

Чтобы не путаться, удобно держать в голове мини-табличку:

И вот тут ключ: Boot создаёт много default-beans так, чтобы их можно было безопасно заменить. Это не побочный эффект, а дизайн. И механизм, который делает это возможным, чаще всего выглядит как одна аннотация — @ConditionalOnMissingBean.

3. @ConditionalOnMissingBean и backoff

Когда вы видите @ConditionalOnMissingBean, полезно переводить её не как «какая-то условная магия», а как очень бытовую фразу:

«Создай этот бин, только если в приложении ещё нет бина такого типа (или с таким именем).»

Это и есть контракт между Boot и вашим приложением. Boot говорит: «Я дам вам вариант по умолчанию, но не буду спорить, если вы объявите свой». За счёт этого вы можете менять поведение приложения точечно, не ломая всё остальное.

Вот как примерно выглядит мыслительный процесс в голове Boot (упрощённо, но честно):

flowchart TD
    A[Boot собирает контекст] --> B[Сначала регистрируются ваши beans]
    B --> C[Потом подключаются auto-config классы]
    C --> D{Нужен default-bean X?}
    D -->|"в auto-config стоит @ConditionalOnMissingBean"| E{Уже есть bean типа X?}
    E -->|да| F[Boot отступает: default не создаём]
    E -->|нет| G[Boot создаёт default-bean]

Обратите внимание на важную деталь: сначала идут бины приложения (user-defined), потом auto-configuration. Именно поэтому “уступание” работает. Если бы порядок был обратный, то Boot успел бы создать default, а потом вы создали бы свой — и у вас получилось бы два бина одного типа, а дальше Spring сказал бы: «Ребята, выберите одного, я не телепат».

Ещё один момент, который постоянно ловит новичков: чаще всего условие “missing bean” проверяет тип, а не имя. То есть не важно, что метод называется startupMessageFormatter() — важно, что возвращаемый тип StartupMessageFormatter. Если вы хотите заменить default, вы должны объявить бин того же смысла и того же типа, а не «похожий по названию».

4. Практика: default + override в catalog-service

Сейчас мы соберём маленький, но очень показательный пример прямо в контексте catalog-service. Мы не будем лезть в реальный Boot-код (это не курс “пишем Spring Boot”), но сделаем учебную инфраструктурную штуку, которая ведёт себя так же, как ведут себя настоящие auto-config defaults.

Идея такая: у нас есть StartupSummaryRunner, который что-то выводит на старте. Мы хотим, чтобы формат сообщения можно было поменять без переписывания раннера. Для этого введём интерфейс-абстракцию StartupMessageFormatter, дадим ему default-реализацию “от платформы”, а потом покажем, как приложение задаёт свой форматтер и Boot-style default «отступает».

Контракт: интерфейс для прикладного кода

Начинаем с самого важного: контракт. Это маленький интерфейс, от которого будет зависеть наш StartupSummaryRunner.

package com.example.catalogservice.support.startup;

public interface StartupMessageFormatter {

    /**
     * Форматирует сообщение для вывода на старте приложения.
     * Здесь специально нет Spring-аннотаций: это чистый контракт.
     */
    String format(String appName);
}

Обратите внимание: тут нет Spring вообще. Это обычная Java. И это хорошо: чем меньше в доменных/прикладных контрактах “привкуса фреймворка”, тем проще их понимать и тестировать.

Default от платформы: бин только если нет своего

Теперь создадим конфигурацию, которая ведёт себя как «платформа дала default». В реальном Spring Boot подобные вещи живут в auto-config классах. Мы сделаем очень маленькую версию, чтобы увидеть паттерн.

package com.example.catalogservice.support.startup;

import org.springframework.boot.autoconfigure.AutoConfiguration;
import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;
import org.springframework.context.annotation.Bean;

@AutoConfiguration // Это именно auto-configuration, а не обычная @Configuration "по скану"
public class StartupSupportAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean // Default создаётся только если пользователь НЕ объявил свой бин того же типа
    StartupMessageFormatter startupMessageFormatter() {
        return (String appName) -> {
            // Дефолтный формат — максимально простой и предсказуемый
            return "Started: " + appName;
        };
    }
}

Здесь всё, ради чего мы собрались:

• @AutoConfiguration — означает «это конфигурация, которую Boot может подключать как часть auto-configuration механизма».
• @ConditionalOnMissingBean — означает «создай default, только если пользователь ещё не создал свой».

Мы специально сделали реализацию через лямбду, чтобы не плодить классы. Сейчас нам важно поведение, а не красота архитектуры.

Подключаем учебный auto-config через imports-файл

Чтобы Boot вообще увидел наш учебный auto-config как auto-configuration кандидата, ему нужен imports-файл. Это не component scan, это отдельный механизм. Пока воспринимайте это как «служебный список конфигураций, которые Boot готов подключать автоматически».

Файл: src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

com.example.catalogservice.support.startup.StartupSupportAutoConfiguration

Да, это буквально список классов построчно. Никаких заклинаний на латыни — всё достаточно прямолинейно (что обычно удивляет тех, кто ожидает магии).

Прикладной код: StartupSummaryRunner зависит от интерфейса

Теперь изменим наш раннер так, чтобы он зависел не от “какого-то конкретного класса”, а от интерфейса. Это и есть тот момент, который делает override безопасным.

package com.example.catalogservice.catalog.bootstrap;

import com.example.catalogservice.support.startup.StartupMessageFormatter;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.stereotype.Component;

@Component
public class StartupSummaryRunner implements ApplicationRunner {

    // Инжектим именно контракт, а не конкретную реализацию:
    // так мы оставляем себе возможность безопасно заменить реализацию без переписывания раннера.
    private final StartupMessageFormatter formatter;

    public StartupSummaryRunner(StartupMessageFormatter formatter) {
        this.formatter = formatter;
    }

    @Override
    public void run(ApplicationArguments args) {
        // Наблюдаемое поведение: выводим строку, чтобы увидеть, какой форматтер реально используется.
        System.out.println(formatter.format("catalog-service")); // Started: catalog-service
    }
}

Смысл в том, что StartupSummaryRunner теперь не знает (и не должен знать), кто именно форматирует сообщение. Он знает только контракт. Это как розетка: вам не важно, какая электростанция в городе — главное, что напряжение “подходит”.

На этом этапе, если вы запустите приложение, вы увидите дефолтное сообщение:

Started: catalog-service

Свой bean: Boot отступает, default не создаётся

Теперь делаем то, ради чего всё затевалось: объявим свой бин того же типа StartupMessageFormatter. И положим его туда, где ему место по архитектуре проекта — в пакет config, чтобы кастомизации не были спрятаны “где-то случайно”.

package com.example.catalogservice.config;

import com.example.catalogservice.support.startup.StartupMessageFormatter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class StartupConfiguration {

    @Bean
    StartupMessageFormatter startupMessageFormatter() {
        // Этот бин имеет тот же тип, что и default, поэтому условие
        // @ConditionalOnMissingBean "провалится", и default из auto-config создан не будет.
        return (String appName) -> {
            // Тут может быть любая логика форматирования: префиксы, окружение, версия и т.д.
            return "[catalog-service] " + appName + " is ready";
        };
    }
}

Теперь при старте StartupSupportAutoConfiguration скажет: «Ага, StartupMessageFormatter уже существует, значит мой default не нужен». И ваш раннер выведет другое:

System.out.println(formatter.format("catalog-service"));
// [catalog-service] catalog-service is ready

То есть вы поменяли одну точку поведения и не трогали остальной Boot-мир. Это и есть «здоровая кастомизация».

5. Интерфейс как страховка для кастомизации

Очень легко попасть в ловушку: «Зачем мне интерфейс, если у меня есть конкретная реализация?». Ловушка срабатывает особенно быстро у новичков, потому что интерфейсы часто воспринимаются как “бюрократия ради бюрократии”. Но в Boot-проектах интерфейс — это не украшение, а способ сделать замену поведения безопасной и дешёвой.

Представьте, что StartupSummaryRunner напрямую инжектит конкретный класс, например DefaultStartupMessageFormatter. Тогда, чтобы заменить поведение, вам пришлось бы либо менять код раннера (то есть трогать прикладной слой ради инфраструктурной правки), либо пытаться “перехитрить” контейнер через @Primary, @Qualifier, переименование и прочие танцы. Это уже не “точечная кастомизация”, а мини-квест.

Когда же раннер инжектит интерфейс, вы получаете аккуратную картину: есть контракт, есть дефолтный вариант от платформы, и есть ваш вариант. Вы можете заменить реализацию, не меняя ни одной строки в потребителе. В больших системах это экономит не минуты — дни, потому что изменения становятся локальными и предсказуемыми.

И ещё один маленький, но важный плюс: интерфейс позволяет вам мысленно отделить “что нужно” от “как сделано”. Это полезно даже без Spring. Spring просто делает такой стиль особенно приятным, потому что wiring берёт на себя контейнер.

6. Проверяем, что override сработал

Когда вы переопределяете поведение через свой бин, важно уметь честно ответить себе на вопрос: «А я точно заменил default, или случайно создал второй бин и теперь всё держится на удаче?». На уровне Junior это особенно важно, потому что первые проблемы обычно выглядят как “почему оно вчера работало, а сегодня нет”.

Самый простой способ проверки в учебном проекте — сделать поведение наблюдаемым. Мы уже это сделали через вывод строки: по ней видно, какой форматтер используется. Иногда полезно временно вывести ещё и класс реализации, чтобы не гадать:

System.out.println(formatter.getClass().getName());
// com.example.catalogservice.config.StartupConfiguration$$Lambda...

Да, имя будет странным (лямбды любят маскироваться), но мысль понятна: вы получаете доказательство, а не ощущение.

Чуть более “инженерный” подход — держать кастомизации в одном видимом месте. Если ваш бин лежит в config, вы всегда знаете, где искать ответ на вопрос «почему формат изменился». Если же вы объявили бин случайно в каком-то @Component, спрятанном в глубине пакетов, вы сами себе создаёте расследование на вечер пятницы.

И последнее: когда вы делаете override, старайтесь формулировать его словами так, чтобы это выглядело как нормальное требование, а не как шаманство. Например: «Мы заменили StartupMessageFormatter на наш вариант, поэтому default-bean из auto-config больше не создаётся». Это звучит скучно — а скучно значит предсказуемо. В инфраструктуре “скучно” обычно комплимент.

7. Типичные ошибки при переопределении default-beans

Ошибка №1: создают “свой бин”, но другого типа — и удивляются, что default не исчез.
Это самая частая ловушка. @ConditionalOnMissingBean обычно проверяет тип. Если default создаётся для StartupMessageFormatter, а вы объявили бин другого контракта или возвращаете не тот тип, который проверяет условие, default никуда не денется. Spring смотрит прежде всего на тип, а не на красивое имя метода. Лечится это просто: всегда проверяйте, какой тип возвращает ваш @Bean-метод, и какой тип стоит в условии.

Ошибка №2: инжектят конкретную реализацию, а потом пытаются “переопределить default”.
Пока вы инжектите интерфейс, замена — это замена. Как только вы инжектите конкретный класс, вы сами себе ломаете возможность мягкого override. В результате приходится либо переписывать код потребителя, либо устраивать сложный wiring с квалификаторами. В учебном проекте это выглядит как “я хотел поменять одну строку, а получил три класса и пять аннотаций”.

Ошибка №3: прячут кастомный бин в случайном месте проекта.
Иногда студент делает @Component-класс где-нибудь в catalog.service и думает: «Ну он же бин, значит всё нормально». Формально — да, но архитектурно вы перемешали бизнес-слой и инфраструктурную кастомизацию. Через неделю вы забудете, почему сервис внезапно отвечает иначе, и начнёте искать “баг”. Правильнее держать такие вещи в пакете config и называть конфигурацию по смыслу.

Ошибка №4: пытаются “заменить default” копированием большого куска конфигурации.
Очень соблазнительно: найти в интернете пример, скопировать целый auto-config класс и “подправить пару строк”. Проблема в том, что вы приносите в проект огромный хвост побочных настроек, которые не понимаете. Сегодня всё работает, завтра при обновлении зависимости — сюрприз. Куда безопаснее начать с узкого override одного бина, который реально влияет на нужную точку поведения.

Ошибка №5: не могут объяснить, что именно изменилось в контексте.
Если после override вы не можете коротко сказать “какой бин теперь используется и почему default не создался”, почти всегда это значит, что решение пока не оформилось в голове. А всё, что не оформилось в голове, обычно оформляется в проде как инцидент. Хорошая привычка — проговаривать: “мы объявили свой bean типа X, поэтому @ConditionalOnMissingBean не прошёл, и default не зарегистрировался”. Это звучит как скучный отчёт — и именно поэтому работает.