[Spring Framework] Bean 등록에 대한 재고 V2

Bean 등록에 대한 재고

이전 포스트에 이어 이번에는 Spring Framework의 자랑! Conditional 시리즈를 활용한 Bean 등록에 대해 작성해보려 한다.

 

시작하며

 

올해 초부터 정말 일이 많다. 뭐.. 갈 수록 쌓여간다. 기술적 백로그만 몇 십 개 정도 되는 듯하다.

덤으로 기술 과제와 부채도 많이 늘어났다. 당장 해결해야 하는 급한 건은 아니지만, 이번 주는 다행히 시간이 여유로운 것 같아 틈틈이 개선을 했다. (블로깅할 소스가 많이 늘어났지만! 시간이 여유롭지 않아 발행 대기 중~)

 

주력으로 맡고 있는 프로젝트는 멀티 모듈형 멀티 bootjar를 가지는 프로젝트이다.

api, consumer, batch 등의 모듈로 관리하는 애플리케이션들이 있는데, 요구사항에 따라 코드 양이 점차 늘어나게 되어 다시 한번 정말 필요한 Bean만을 등록해야 되겠다는 생각이 스프린트를 진행하며 들었다. 이 스프린트가 끝나고 배포하면, 기필코 개선해 보리라!!

 

그래서 어제부터 SpringFramework의 Condition을 적극 활용하여 개선 작업을 했다.

V1 버전에 비해 좀 더 손쉽게, 애노테이션 기반으로 조건부 Bean 등록을 할 수 있게 ㅎㅎ

 

그 과정과 결과를 한번 공유해보려 한다.

 

Condition, Conditional Configuration의 자랑

아래 예시 멀티 모듈들을 살펴보자.
- api (BootJar)
- batch (BootJar)

- application
- core
- infrastructure
- consumer (BootJar)

  

현재 프로젝트의 구조이다.

core는 도메인 및 관련 비즈니스, 곧 순수 POJO와 public interface를 가진다.

application 은 Use Case를 다룬다.

infrastructure에서 각종 외부 설정과 public interface에 대한 구현체를 담당하는 모듈인데, 조건부 bean 등록이 필요한 녀석이다.

 

우리 팀에서 담당하는 프로젝트는 최소 2, 3개의 DB를 물게 되는데, 이를 auto configuration 형태로 모든 BootJar에서 Bean 로드되어 사용 중이었다.

프로젝트가 커지면서 생성하는 테이블, 그리고 infra saas, 외부 http Client 설정 등이 많아지면서 특정 BootJar에서 불필요한, 정확히는 몰라도 되는 Bean들도 빌드되었다.

 

일단 필요한 DB Dao Bean부터 분리하겠다.

 

SpringFramework에서 제공하는 interface 중 Conditional이라는 애노테이션이 있다.

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Conditional {
    Class<? extends Condition>[] value();
}

 

이 애노테이션은 Condition interface를 상속하는 value 속성을 갖는데, 이는 Functional interface이다.

@FunctionalInterface
public interface Condition {
    boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata);
}

 

이를 내가 원하는 Bean 등록 형태에 알맞게 구현하여 Conditional 애노테이션에 제공하면 될 것이다.

 

Custom annotation

조건부 Bean 등록을 쉽게 하기 위해 커스텀 애노테이션을 만들었다.

@Target(AnnotationTarget.CLASS, AnnotationTarget.FUNCTION)
@Retention(AnnotationRetention.RUNTIME)
@Conditional(ApplicationTypeCondition::class)
annotation class ConditionalOnApplicationType(
    vararg val types: String,
    val matchIfMissing: Boolean = false,
)

 

위와 같이 작성을 했고, Conditional 애노테이션 속성으로 커스텀 condition을 지정하기 위해 아래와 같은 class를 구현했다.

class ApplicationTypeCondition : Condition {
    override fun matches(
        context: ConditionContext,
        metadata: AnnotatedTypeMetadata,
    ): Boolean {
        val applicationType = context.environment.getProperty("application.type")
        val attributes =
            metadata.getAnnotationAttributes(
                ConditionalOnApplicationType::class.java.name,
            )

        val types = attributes?.get("types") as Array<*>?
        val matchIfMissing = attributes?.get("matchIfMissing") as Boolean? ?: false

        return when {
            applicationType == null -> matchIfMissing
            types == null -> matchIfMissing
            else -> types.contains(applicationType)
        }
    }
}

 

최종 사용 형태는 아래와 같다.

@Component
@ConditionalOnApplicationType("api", "consumer")
class DBBusinessReader(
    private val jpaDao: JpaBusinessesDao,
) : BusinessReader {
	// ...
}

// 아래와 같이 configuration 에도 사용 가능
@Configuration
@ConditionalOnApplicationType("api", "batch", "consumer")
@EnableJpaRepositories(
    basePackages = ["infra.db.apple"],
    entityManagerFactoryRef = APPLE_ENTITY_MANAGER_FACTORY,
    transactionManagerRef = APPLE_JPA_TRANSACTION_MANAGER
)
class AppleDatabaseConfig : DatabaseConfigurationBase("apple") {
	// ...
}

 

 

실행하는 BootJar의 프로퍼티를 읽어 type 을 얻고, 그 type 과 속성이 일치하면 Bean 등록을 하는 간단한 형태이다.

BootJar 의 type의 형태는 아래와 같이 application.yml 에 프로퍼티로 설정하면 된다.

application:
  type: api

 

그럼 실제로 지정한 type 별 애플리케이션 실행 시, 조건부로 Bean 등록이 되는 것을 확인할 수 있다.

 

기존에는 각 모듈 별 configuration 파일에 직접 Bean 등록을 했는데, 이렇게 했을 때 중복 되는 코드들이 생겼다.

이 커스텀을 통해 편리하게 애노테이션 형태로 조건부 Bean 등록을 쉽게 진행할 수 있게 되었다.

 

마치며

개발하며 항상 생각을 많이 하는 편인데, 특히 책임을 명확히 하려는 편이다.

책임에 맞게 배치하고 지정하는 것이 결국 유지보수를 쉽게 하기 때문이다.

어떻게 하면 좀 더 쉽고, 간편하게 할 수 있을까란 생각을 매번 하는데 혼자 하는 것이 아닌 결국 코드는 공유되기에, 남 보기 편하게 더 신경을 쓰게 되는 것 같다.

 

멀티 애플리케이션 구조의 프로젝트에서 Spring의 핵심인 Ioc를 더 책임에 맞게 활용하는 것도 결국 마찬가지란 생각이 든다.

사용하지 않는 의존성을 그대로 물고 올라갈 필요가 없기 때문이다.

 

좀 더 깔끔하게, 그리고 완성도 있게 application 구조를 잡아나가는 밑거름이 되었으면 좋겠다!