feat: ImportSelector 기반 모듈별 인프라 선택 적용 기능 도입 #6
Conversation
- @async 메서드 실행을 위한 Executor를 taskExecutor()로 분리 구성 - 이벤트 리스너의 실행도 비동기로 처리되도록 ApplicationEventMulticaster 재정의 - 각 기능별 Executor를 분리하여 용도에 맞는 설정을 구성
- 트랜잭션 관리 활성화를 위한 @EnableTransactionManagement 적용 - JPA 엔티티 스캔 경로 지정 (@EntityScan) - JPA 리포지토리 스캔 경로 지정 (@EnableJpaRepositories)
- AsyncConfig와 JpaConfig를 그룹에 포함시켜 모듈별 인프라 선택 등록에 활용 - 추후 Config 클래스 추가 시 해당 enum에 반드시 명시
- InfraBaseConfigGroup 배열을 받아 필요한 인프라 설정만 선택적으로 등록할 수 있도록 설계
- EnableInfraBaseConfig 어노테이션에 지정된 InfraBaseConfigGroup 열거형 값을 기반으로, 각 모듈에서 필요한 인프라 설정 클래스만 선택적으로 스프링 빈으로 등록하도록 구현 - DeferredImportSelector 인터페이스를 구현하여, 스프링 애플리케이션 컨텍스트 초기화 시점에 필요한 설정만 지연해서 임포트함으로써 불필요한 빈 등록을 방지
- Admin 모듈 InfraConfig에 @EnableInfraBaseConfig 어노테이션 적용 - InfraBaseConfigGroup.JPA 설정을 통해 JPA 관련 빈만 선택적으로 등록하도록 구성
- Apis 모듈 InfraConfig에 @EnableInfraBaseConfig 어노테이션 적용 - InfraBaseConfigGroup.JPA와 ASYNC 설정을 통해 필요한 인프라 빈을 선택적으로 등록
- Batch 모듈 InfraConfig에 @EnableInfraBaseConfig 어노테이션 적용을 위한 어노테이션 주석 추가 - 향후 @EnableInfraBaseConfig([InfraBaseConfigGroup.FCM])로 FCM 인프라 설정 모듈 자동 등록 예정
|
|
||
| private fun getValues(metadata: AnnotationMetadata): Array<InfraBaseConfigGroup> { | ||
| val attributes = metadata.getAnnotationAttributes(EnableInfraBaseConfig::class.java.name) | ||
| @Suppress("UNCHECKED_CAST") |
There was a problem hiding this comment.
결론적으로는 Spring에서 어노테이션 파싱 시 타입을 보장해주기 때문에, 관련한 컴파일러의 경고를 끄기 위해서였습니다.
런타임에는 Java 5 이전 버전과의 호환성을 유지하기 위해 제네릭의 타입 정보가 소거(type erasure) 됩니다.
따라서 컴파일러는 Array처럼 구체적인 타입 정보를 런타임에 확인할 수 없다는 점에서 경고를 발생시키게 됩니다.
이는 “정말로 이 타입이 맞는지 런타임에 보장할 수 없는데 괜찮겠느냐?“는 의미의 경고입니다.
하지만 Spring 프레임워크는 어노테이션을 파싱할 때 내부적으로 타입 정보를 정확하게 처리해주기 때문에,
@EnableInfraBaseConfig에 선언된 InfraBaseConfigGroup 배열 타입은 안전하게 사용할 수 있습니다.
따라서, 스프링에서 보장해주기 때문에 관련 경고를 끄기 위하여 사용했습니다!
| @Bean(name = ["taskExecutor"]) | ||
| fun taskExecutor(): Executor { | ||
| val executor = ThreadPoolTaskExecutor() | ||
| executor.corePoolSize = 3 | ||
| executor.setThreadNamePrefix("async-") | ||
| executor.setWaitForTasksToCompleteOnShutdown(true) | ||
| executor.setAwaitTerminationSeconds(30) | ||
| executor.initialize() | ||
| return executor | ||
| } |
There was a problem hiding this comment.
예시코드이자, 실전에 사용을 염두해두고 짠 코드긴 합니다!
| @EntityScan("org.yapp") | ||
| @EnableJpaRepositories("org.yapp") | ||
| class CoreDomainConfig { | ||
| } |
There was a problem hiding this comment.
저도 동일한 생각입니다.
domain 모듈에서는 Repository interface만 정의하고, 설정은 전혀 포함하지 않는 것이 더 바람직해 보입니다.
별도의 구현체는 infra 계층에서 구성하고, 필요한 경우 교체 가능한 형태로 가져가는 구조가 좋다고 생각합니다!
|
infra 모듈에서 repository 구현체를 관리할 지 의견을 주시면 감사할 것 같습니다. (저는 Infra 모듈은 각종 Config, 외부 API 통신을 관리하기에 별도 모듈을 또 만드는 방식이 나을 것 같다는 생각입니다. |
|
제가 생각한 구조입니다 domain/ infra/ infra는 domain의 모델과 레포지토리 인터페이스를 가져와서 실제 DB 연동을 구현 infra는 @EntityScan, @EnableJpaRepositories 설정을 통해 자동 구현체 생성 domain은 순수 비즈니스 계층 → 설정 없이 interface와 model만 제공 // infra/src/main/kotlin/org/yapp/infra/config/JpaConfig.kt import org.springframework.boot.autoconfigure.domain.EntityScan @configuration 의존성 방향 infra → domain (O) domain → infra (X) |
민우님 의견 주셔서 감사합니다 ㅎㅎ 아 그리고, 저도 다시 생각해보니 repository 구현체를 infra 모듈에서 관리하는 부분에 대해서는 긍정적인 입장으로 바뀌었습니다 😊 처음에는 DB를 외부 시스템과는 좀 다른 범주로 생각했었는데, 결국 DB도 외부 API와 마찬가지로 외부 시스템에 해당하고, |
도메인만의 Config 클래스를 별도로 구현을 해야할 것 같네요! -> 이 방향 너무좋은 것 같아요! 이 방향으로 config 셋팅 진행해주시면 될 것 같아요~ |
🔗 관련 이슈
📘 작업 유형
📙 작업 내역
🧪 테스트 내역
🎨 스크린샷 또는 시연 영상 (선택)
✅ PR 체크리스트
💬 추가 설명 or 리뷰 포인트 (선택)
새로운 InfraStructure 관련 모듈 생성? or 기존 infra 모듈 내부에 구현
domain 모듈은 별도의 Config 클래스를 생성해서 infra 모듈에 의존하지 않고 별도 관리
편하게 읽어주시고 천천히 리뷰달아주시면 감사하겠습니다 🙇🏻♂️