На сегодняшний день spring stack - практически “стандарт” в мире java разработки, огромное количество IT-компаний разрабатывают свои приложения с использованием этих технологий. Сегодня мы напишем свой starter для spring-boot приложения.

Те, кто создают свои проекты с использованием spring-boot, знают, что с его приходом появилась прикольная фича - ConfigurationProperties, которая позволяет “мапить” ваш environment на Java объекты. Подробно об этом можно почитать в официальной документации.

Используя @ConfigurationProperties, можно получить более понятный и читаемый код. Например, у вас есть конфиг приложения application.yml, который описывает настройку интеграции с сервисом «Почта России»:

app:
    russianpost:
        apiUrl: https://tracking.russianpost.ru/fc
        user: user
        password: password

До spring-boot мы инжектили подобные параметры, используя аннотацию @Value, и получали нечто подобное:

@Component
public class RussianPostServiceClient {
    @Value("${app.russianpost.apiUrl}")
    private String apiUrl;

    @Value("${app.russianpost.user}")
    private String user;

    @Value("${app.russianpost.password}")
    private String password;
}

Представьте, если ваш клиент в конфигурации будет еще иметь такие параметры, как readTimeout, connectionTimeout или любые другие. Размер класса RussianPostServiceClient будет расти, а его читаемость падать. Если нам потребуются эти параметры в другом классе, то опять придётся их получать через @Value:

@Component
public class SomeOtherComponent {
    @Value("${app.russianpost.apiUrl}")
    private String apiUrl;
}

При использовании @ConfigurationProperties это выглядит так: мы создаем класс Java, на полях которого будут мапиться параметры из конфига, а Spring всё сделает за нас:

@Data
@ConfigurationProperties("app.russianpost")
public class RussianPostProperties {
    private String apiUrl;
    private String user;
    private String password;
}

Далее нам необходимо зарегистрировать BeanDefinition данного класса для получения бина из контекста Spring’а. Это делается при помощи аннотации @EnableConfigurationProperties.

@Configuration
@EnableConfigurationProperties(RussianPostProperties.class)
public class PropertyConfiguration {

}

Теперь мы можем инжектить наш объект в любой другой, управляемый Spring’ом, например, RussianPostServiceClient

@Component
public class RussianPostServiceClient {
    @Autowired
    private RussianPostProperties properties;
}

Выглядит намного лучше, чем использование @Value, не правда ли?
Теперь RussianPostProperties находится в контексте, и мы можем инжектить его в любой другой бин. Также мапинг через @ConfigurationProperties позволяет произвести валидацию конфига, например, указать, что поля apiUrl, user, password - обязательны.

На примере такого маленького приложения всё выглядит очень неплохо, но в приложениях посерьёзней подобных конфигов, которые надо мапить на классы, гораздо больше. В итоге ваш конфиг превращается в:

@Configuration
@EnableConfigurationProperties({
    RussianPostProperties.class,
    SomeProperty1.class,
    SomeProperty2.class,
    SomeProperty3.class,
    SomeProperty4.class,
    .......
})

За этим надо постоянно следить и не забывать добавлять следующий Property class. Либо вы можете объявить ваш Property class как компонент, добавив аннотацию @Component над классом RussianPostProperties, тогда @EnableConfigurationProperties не понадобится, она применится автоматически. Сам Spring не рекомендует этого делать. Объяснения тут.

Чтобы не писать ни того, ни другого, я написал Spring Boot starter. Вместе со Spring Boot’ом пришла концепция starter’ов. Это некая конвенция управления зависимостями в spring-boot проектах.

Вашему проекту нужна работа с базой данных? Добавляем в проект зависимость

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

и автоматически получаем преднастроенные конфигурации для работы с БД (spring data, hibernate, а также системы управления версионностью БД, при наличии таковых в зависимостях проекта). Это тоже косвенно позволяет делать ваш проект немного «чище». Раньше приходилось подключать намного большее количество зависимостей.