Архитектурный подход к бобам - PullRequest
Новая
       36

Архитектурный подход к бобам

0 голосов
/ 12 марта 2020

Я пытаюсь разбить монолитное приложение java на несколько микросервисных приложений с интерфейсом отдыха. Приложение состоит из нескольких модулей платежного сервиса (отдельный модуль для каждой системы). Я хочу создать конфигурацию Spring, которая объявляет список необязательных bean-компонентов, основанных на свойствах, которые содержат информацию о соединении, например: 

application.properties:
service.first.enabled=true
service.second.enabled=true
service.third.enabled=false

Тогда я думаю, что у меня будет соответствующий POJO: 

public class PaymentService{
    private String host;
    provate String port;
    // other properties, getters & setters...
}

В классе BeanConfig я бы объявил что-то вроде: 

@Configuration
public class BeanConfig {

    @Bean("first")
    @ConditionalOnProperty(value="first.enabled", on=false, propertiesBeanName="service")
    public PaymentSystem firstService(){
        return new PaymentSystem("localhost", "10000")
    }

    @Bean("second")
    @ConditionalOnProperty(value="second.enabled", on=false, propertiesBeanName="service")
    public PaymentSystem firstService(){
        return new PaymentSystem("localhost", "11000")
    }

    @Bean("third")
    @ConditionalOnProperty(value="third.enabled", on=false, propertiesBeanName="service")
    public PaymentSystem firstService(){
        return new PaymentSystem("localhost", "12000")
    }
}

Но на самом деле мне нужно иметь одноэлементный компонент, содержащий эти условные компоненты, чтобы я мог автоматически связать соответствующие настройки с сервисом по типу ... я думаю, что есть что-то лучше, чем autowire эти бобы по определителю ...

Кто-нибудь может посоветовать любой дизайн, который соответствует моей цели?

ps: я мог бы ошибиться в некоторых деталях, потому что у меня еще нет прототипа, поэтому, пожалуйста, не сосредотачивайтесь на деталях.

...