← 모든 글
Spring

2-5. Explicit Application Module Dependencies

기본적으로 Spring Modulith의 모듈들은 다른 모든 모듈이 노출한 제공 인터페이스(API)를 자유롭게 참조할 수 있어요.

by rati·

기본적으로 Spring Modulith의 모듈들은 다른 모든 모듈이 노출한 제공 인터페이스(API)를 자유롭게 참조할 수 있어요. 하지만 특정 모듈에 대한 의존성만 강제할 수도 있어요.

이럴 때 사용하는 기능이 바로 명시적 애플리케이션 모듈 의존성(Explicit Application Module Dependencies) 이에요.

이 의존성은 package-info.java 패키지 선언부에 @ApplicationModule 어노테이션의 allowedDependencies 속성을 지정해서 설정할 수 있어요.

// example/inventory/package-info.java
@ApplicationModule(allowedDependencies = "order")  
package example.inventory;  
  
import org.springframework.modulith.ApplicationModule;
package example.inventory 

import org.springframework.modulith.ApplicationModule

@ApplicationModule(allowedDependencies = "order") 
class ModuleMetadata {}

이 경우, inventory 모듈이 오직 order 모듈과 범용 공통 코드에만 의존할 수 있어요. 다른 모듈을 임포트하게 되면, 아키텍처 검증 테스트를 돌릴 때 에러가 발생해요.

**TIP · > Kotlin 같이 package-info.java 작성을 지원하지 않는 언어에서는, 패키지 대신 애플리케이션 모듈 루트 패키지에 있는 **단일 타입(예: 클래스나 인터페이스)에 @ApplicationModule 어노테이션을 직접 붙여서 설정할 수 있어요.

의존성을 모니터링하고 테스트로 검증하는 구체적인 방법은 Verifying Application Module Structure 문서를 참고해주세요.

장점

  • 의존성 흐름을 명확하게 한 방향 혹은 특정 모듈로만 흐르게 제한하여, 스파게티 의존성을 완벽하게 예방할 수 있다.
  • 개발자가 실수로 엉뚱한 모듈의 API를 호출하는 결합도 상승 현상을 검증 과정에서 확실히 방지할 수 있다.

단점

  • 비즈니스 로직 변화에 따라 의존성이 수정될 때마다 어노테이션의 허용 목록을 수동으로 갱신해줘야 한다.
  • 프로젝트 전체의 아키텍처 규칙이 복잡해질 수 있어, 신규 팀원들의 규칙 학습 시간이 필요할 수 있다.
끝까지 읽어주셔서 감사합니다.
DISCUSSION

이 글에 대해 이야기해요

질문이나 다른 관점을 남겨 주세요.