Spring Boot 4. Новые модули. Зачем?

Статья предназначена для разъяснения концепции «модуляризации» в Spring Boot, её происхождения и причин появления. Spring Boot часто ассоциируется исключительно с автоконфигурацией, однако его функциональность гораздо шире. Помимо автоконфигурации, он включает в себя такие компоненты, как Spring Boot Actuator, Spring Boot DevTools, Spring Boot Tools и другие. Когда на собеседовании спрашивают о различиях между Spring Boot и Spring Framework, первое, что приходит в голову многим, — это автоконфигурация. До появления Spring Boot разработчикам приходилось вручную настраивать взаимодействие с базой данных, используя @Configuration и @Bean. С внедрением Spring Boot процесс значительно упростился: теперь достаточно указать параметры подключения в конфигурационном файле, а Spring Boot автоматически создаст необходимый DataSource. Однако у такой универсальности есть обратная сторона. В Spring Boot долгое время существовал крупный модуль spring-boot-autoconfigure, который содержал автоконфигурации для всех поддерживаемых технологий — от Apache Cassandra до Apache Pulsar. При использовании Spring Boot разработчик подключал spring-boot-starter-data-jdbc и вместе с ним транзитивно получал spring-boot-autoconfigure. Это означало, что в проект загружались автоконфигурации для всех технологий, поддерживаемых Spring Boot, даже если использовались лишь некоторые из них. Дизайн предполагал, что в процессе выполнения программы будет определено, какие автоконфигурации действительно необходимы. Благодаря аннотациям типа @ConditionalOnClass и инструментам вроде ASM и SimpleAnnotationMetadata, Spring Boot мог определить, какие автоконфигурации следует загрузить, не подгружая при этом классы, не относящиеся к проекту. Тем не менее наличие большого количества автоконфигураций в Class Path могло влиять на производительность и оптимизировать этот процесс было необходимо.