TIL

Fundamentals

• 스프링 모듈리스는 스프링 부트 애플리케이션에서 논리적 모듈을 구현하는 개발자를 지원한다.
  • 구조적 유혀성을 검증
  • 모듈의 구조를 문서화
  • 각 모듈에 대한 통합 테스트 실행
  • 모듈 간 런타임 상호작용 관측
  • 느슨한 결합으로 모듈 간 협력 구현

Application Modules

• 스프링부트 애플리케이션에서의 모듈 구성 요소
  • 스프링 빈에 의해 구현된 다른 모듈에 노출되는 API
  • 모듈이 공개한 애플리케이션 이벤트
  • 다른 모듈이 접근해서는 안되는 내부 구현 요소
  • 스프링 빈 종속성 형태로 다른 모듈에 노출된 API에 대한 참조
  • 수신된 애플리케이션 이벤트
  • 노출된 설정 프로퍼티 정보

ApplicationModules

• 스프링 모듈리스를 통해 코드를 검사하여 주어진 배열과 선택적 구성을 기반으로 모듈 모델을 도출할 수 있다.
• spring-modulith-core에는 스프링 부트 애플리케이션 클래스를 가리킬 수 있는 ApplicationModules이 포함되어 있다.

var modules = ApplicationModules.of(Application::class)

• 위 코드의 modules에는 코드베이스에서 파생된 애플리케이션 모듈의 배열의 인메모리 표현이 들어있다.
• 모듈로 감지되는 부분은 클래스가 가리키는 패키지 하위의 Java 패키지 구조에 따라 달라진다.
• modules를 순회하며 출력하면 아래처럼 구조를 볼 수 있다.

## example.inventory ##
> Logical name: inventory
> Base package: example.inventory
> Spring beans:
  + ….InventoryManagement
  o ….SomeInternalComponent

## example.order ##
> Logical name: order
> Base package: example.order
> Spring beans:
  + ….OrderManagement
  + ….internal.SomeInternalComponent

• 특정 클래스 또는 전체 패키지를 제외하려면 아래와 같이 하면 된다.

ApplicationModules.of(
  Application::class, 
  JavaClass.Predicates.resideInAPackage("com.example.db")
).verify()

Simple Application Modules

• 애플리케이션의 main package는 메인 애플리케이션 클래스가 상주하는 곳이다.
  • @SpringBootApplication 어노테이션이 존재하는 클래스가 있는 곳
• 기본적으로 main package 바로 밑의 sub-package는 application module package로 간주된다.
  • 이 sub-package 하위에 속하지 않으면 단순 패키지로 간주되며 의존성 주입 대상이 아니게 된다.

Advanced Application Modules

• application module package에 하위 패키지에 위치하는 타입은 다른 모듈에서 참조하려면 public일 필요가 있다.

 Example
└─  src/main/java
   ├─  example
   |  └─  Application.java
   ├─  example.inventory
   |  ├─  InventoryManagement.java
   |  └─  SomethingInventoryInternal.java
   ├─  example.order
   |  └─  OrderManagement.java
   └─  example.order.internal
      └─  SomethingOrderInternal.java

• 위 구조에서 order 패키지는 API 패키지로, 다른 모듈에서 참조할 수 있도록 내부 타입은 public일 것이다.
• order.internal 패키지는 하위 패키지인 점은 같지만 다른 모듈에서 참조해선 안 된다.
  • 하지만 OrderManagement가 SomethingOrderInternal을 의존한다면 SomethingOrderInternal은 public이어야 하고 Java 컴파일러는 다른 모듈이 order.internal 내부를 참조하는 것을 막아주지 못한다.

Open Application Modules

• 위 패키지 구조 예시는 다른 모듈로 노출할 패키지를 선택하고 제한하기에 닫힌 배열로 간주된다.
• 스프링 모듈리스를 레거시 애플리케이션에 적용할 때 중첩된 패키지에 있는 모든 타입을 다른 모듈에서 숨기는 것이 적절하지 않거나 노출을 위해 모든 패키지를 공개해야 할 수 있다.
• 애플리케이션 모듈을 오픈시키려면 @ApplicaitonModule 어노테이션을 package-info.java 타입에 선언하면 된다.

@org.springframework.modulith.ApplicationModule(
  type = Type.OPEN
)
package example.inventory

• 애플리케이션 모듈을 open 시킨다는 것은 다음과 같이 검증이 변경된다.
  • 다른 모듈에서 애플리케이션 모듈의 internal 타입에 접근하는 것이 허용된다.
  • 명시적으로 명명된 인터페이스에 할당되지 않는 한 모든 타입이 unnamed named interface에 추가된다.

Explicit Application Module Dependencies

• 모듈은 @ApplicationModule 애노테이션을 사용하여 허용되는 종속성을 선언하도록 선택할 수 있다.

package example.inventory

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

• 위 코드에서 inventory 모듈 내 코드는 order 모듈의 코드만 참조할 수 있다.

Named Interfaces

• 기본적으로 모듈의 base package는 API 패키지이고 때문에 다른 모듈에서의 의존이 허용된다.
• 다른 모듈로 추가적인 패키지를 노출하고 싶은 경우 named interface를 사용해야 한다.
  • @NamedInterface 애노테이션을 package-info.java 파일에 선언
  • 혹은 @PackageInfo 애노테이션을 타입에 명시적으로 선언

 Example
└─  src/main/java
   ├─  example
   |  └─  Application.java
   ├─ …
   ├─  example.order
   |  └─  OrderManagement.java
   ├─  example.order.spi
   |  ├—  package-info.java
   |  └─  SomeSpiInterface.java
   └─  example.order.internal
      └─  SomethingOrderInternal.java

// example.order.spi 내부의 package-info.java 파일
package example.order.spi

import org.springframework.modulith.PackageInfo
import org.springframework.modulith.NamedInterface

@PackageInfo
@NamedInterface("spi")
class ModuleMetadata {}

• 위 애노테이션 선언의 두 가지 효과
  • 다른 모듈의 코드가 SomeSpiInterface를 참조 가능
  • 애플리케이션 모듈은 명시적 종속성 선언에서 named interface를 참조할 수 있다.
• inventory 모듈에서 이를 사용해야 한다면 위에서 선언한 named interface를 아래와 같이 참조할 수 있다.

@org.springframework.modulith.ApplicationModule(
  allowedDependencies = "order :: spi"
)
package example.inventory

• named interface의 이름 spi를 ::을 통해 연결하는 것에 유의하라
  • 이 설정에서 inventory 모듈은 SomeSpiInterface 및 order.spi 하위에 있는 코드를 의존할 수 있다.
  • order 코드는 반대로 inventory를 의존할 수 없다.
• 명시적으로 설명된 의존성이 없는 모듈의 경우 애플리케이션 모듈의 루트 패키지와 spi 패키지 모두에 엑세스할 수 있다.

Customizing Module Detection

• 기본적으로 애플리케이션 모듈은 Spring Boot 애플리케이션 클래스가 있는 패키지 바로 하위의 패키지에 위치한다.
• 다른 탐지 전략은 Spring Modulith의 @ApplicationModule 또는 jMolecules @Module 애노테이션을 통해 명시적으로 애노테이션이 있는 패키지만 고려하도록 활성화할 수 있다.

spring.modulith.detection-strategy=explicitly-annotated

• ApplicationModuleDetectionStrategy의 구현체를 제공하여 모듈 탐지 전략을 커스텀할 수도 있다.

spring.modulith.detection-strategy=example.CustomApplicationModuleDetectionStrategy

package example

class CustomApplicationModuleDetectionStrategy : ApplicationModuleDetectionStrategy {

  override fun getModuleBasePackages(basePackage: JavaPackage): Stream<JavaPackage> {
    // Your module detection goes here
  }
}

Customizing the Application Modules Arrangement

• @Modulithic 애노테이션이 있는 스프링부트 애플리케이션 클래스의 핵심 관심사를 구성할 수 있도록 스프링 모듈리스는 제공한다.

package example

import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication
import org.springframework.modulith.Modulithic

@Modulithic
@SpringBootApplication
class DemoApplication

fun main(args: Array<String>) {
  runApplication<DemoApplication>(*args)
}