TIL

03. Working with Application Events

https://docs.spring.io/spring-modulith/reference/events.html

• 애플리케이션 모듈을 가능한 분리된 상태로 유지하려면 이벤트를 주요 상호 작용 수단으로 사용해야 한다.

@Service
class OrderManagement(val inventory: InventoryManagement) {

  @Transactional
  fun complete(order: Order) {
    inventory.updateStockFor(order)
  }
}

• 위의 complete() 메서드는 다른 애플리케이션 모듈에 정의된 스프링 빈과 상호 작용하고 있다.
  • 특히 OrderManagement 인스턴스를 생성하기 위해 의존하는 빈이 필요하기에 테스트하기 까다로워진다.
• 또한 비즈니스 이벤트인 주문 완료에 추가 기능을 통합하고 싶을 때마다 위 클래스를 수정해야한다.
• 이러한 문제를 방지하기 위해 아래처럼 이벤트를 사용할 수 있다.
  • 다른 스프링 빈에 직접 의존하는 대신 도메인 이벤트를 발행

@Service
class OrderManagement(val events: ApplicationEventPublisher, val dependency: OrderInternal) {

  @Transactional
  fun complete(order: Order) {
    events.publishEvent(OrderCompleted(order.id))
  }
}

• 이벤트 발행은 기본적으로 동기적으로 일어나기에 트랜잭션의 범위는 동일하게 유지된다.
• 여러 애플리케이션 모듈 간의 일관성 모델을 간단하게 얻을 수 있다는 장점도 있지만 한 모듈의 에러로 전체 트랜잭션이 실패할 수도 있다는 단점도 있다.
• 이벤트 발행을 트랜잭션을 분리하여 처리할 수도 있다.
  • 커밋 시 이벤트 소비 + 비동기
  • 하지만 이 방법은 이벤트 소비가 실패 시 안전망이 없다면 이벤트 발행이 손실되는 위험도 발생한다.

@Component
class InventoryManagement {

  @Async
  @TransactionalEventListener
  fun on(event: OrderCompleted) { /* … */ }
}

Application Module Listener

• 커밋 후 이벤트를 소비하면서 새로운 트랜잭션을 사용하려면 아래처럼 사용해야 한다.

@Component
class InventoryManagement {

  @Async
  @Transactional(propagation = Propagation.REQUIRES_NEW)
  @TransactionalEventListener
  fun on(event: OrderCompleted) { /* … */ }
}

• Spring Modulith는 위 세 애너테이션을 한 번에 적용하는 @ApplicationModuleListener를 제공한다.

@Component
class InventoryManagement {

  @ApplicationModuleListener
  fun on(event: OrderCompleted) { /* … */ }
}

The Event Publication Registry

• Spring Modulith는 스프링 프레임워크의 핵심 이벤트 발행 메커니즘에 연결되는 이벤트 발행 레지스트리와 함께 제공된다.
• 이벤트를 발행하면 이벤트를 전달 받을 트랜잭션 이벤트 리스너를 찾아 각 리스너에 대한 항목을 원리 비즈니스 트랜잭션의 일부로 이벤트 발행 로그에 기록한다.

• 각 트랜잭션 이벤트 리스너는 실행이 성공하면 해당 로그 항목을 완료된 것으로 처리한다.
  • 리스너가 실패하는 경우에도 로그는 유지되기에 애플리케이션 필요에 따라 재시도 메커니즘을 배포할 수도 있다.
  • 기본적으로 모든 불완전한 이벤트 발행이 애플리케이션 시작시 다시 제출된다.

Spring Boot Event Registry Starters

• 트랜잭션 이벤트 발행 로그를 사용하려면 애플리케이션에 추가한 아티팩트의 조합이 필요하다.
• Spring Modulith는 사용할 영속성 기술을 중심으로 하는 스타터 종속성을 제공한다.
  • spring-modulith-starter-jpa
  • spring-modulith-starter-jdbc
  • spring-modulith-starter-mongodb
  • spring-modulith-starter-neo4j

Managing Event Publications

• 이벤트 발행은 런타임 동안 다양한 방식으로 관리해야 할 수 있다.
  • 불완전한 이벤트 발행은 일정 시간 경과 후 해당 리스너에 다시 제출해야할 후도 있다.
  • 완료된 이벤트 발행은 DB에서 제거하거나 아카이브 저장소로 이동해야 할 수도 있다.
• Spring Modulith는 두 가지 종류의 발행을 모두 처리할 수 있는 API를 제공한다.
  • spring-modulith-events-api
• 이 아티팩트에는 스프링 빈으로 사용할 수 있는 두 가지 기본 추상화(인터페이스)가 포함되어 있다.
  • CompletedEventPublications
    • 완료된 모든 이벤트 발행에 접근 가능
    • DB 등에서 모든 완료된 이벤트 발행을 제거할 수 있는 API 제공
  • IncompleteEventPublications
    • 모든 불완전한 이벤트 발행에 접근 가능
    • 지정된 predicate에 일치하거나 발행 날짜를 기준으로 지정된 Duration 보다 오래된 것을 다시 제출할 수 있다.

Event Publication Repositories

• 이벤트 발행 로그를 기록하기 위해 Spring Modulith는 다음을 제공한다.
  • EventPublicationRepository SPI
  • JPA, JDBC, MongoDB 등의 트랜잭션 지원 기술을 제공하는 구현체
• JDBC 기반 구현은 이벤트 발행 로그를 위한 전용 테이블을 생성할 수 있게 해준다.
  • spring.modulith.events.jdbc.schema-initialization.enabled=true

Event Serializer

• 각 로그에는 직렬화된 원본 이벤트가 포함되어 있다.
• spring-modulith-events-core에 포함된 EventSerializer 추상화를 통해 이벤트 인스턴스를 데이터 저장소에 적합한 형식으로 변환하는 방법에 대한 다양한 전략을 사용할 수 있다.
• Spring Modulith는 기본적으로 스프링 부트 자동 구성을 통해 Jackson 라이브러리를 통한 JSON 구현을 제공한다.

Customizing the Event Publication Date

• 기본적으로 이벤타 발행 레지스트리는 Clock.systemUTC()가 반환한 날짜를 이벤트 발행 시간으로 사용한다.
• 이를 커스터마이징하려면 애플리케이션 컨텍스트에 Clock 빈을 등록하면 된다.

Externalizing Events

• Spring Modulith를 통해 선택한 이벤트를 다양한 메시지 브로커에 발행할 수 있다.
• 외부 브로커를 사용하려면 다음 단계를 따라야 한다.
  1. 프로젝트에 필요한 메시지 브로커 종속성을 추가 (spring-modulith-events-{메시지 브로커 이름})
  2. Spring Modulith 또는 jMolecules의 @Externalized 어노테이션을 사용하여 외부화할 이벤트 타입 선택
  3. 어노테이션 값에 브로커별 라우팅 대상을 지정한다.

Supported Infrastructure

• spring-modulith-events-kafka
• spring-modulith-eventsamap
• spring-modulith-events-jms
• spring-modulith-events-aws-sqs
• spring-modulith-events-aws-sns

Fundamentals of Event Externalization

1. 이벤트의 외부화 여부 결정
2. @Externalized 어노테이션을 통해 외부화 이벤트 선택
3. 이벤트 매핑 (선택 사항)
4. 기본적으로 이벤트는 Jackson을 사용하여 JSON으로 직렬화되어 발행된다.
5. 매핑 단계를 통해 개발자는 표현을 커스터마이징하거나 외부 브로커에 적합한 표현으로 대체할 수도 있다.
6. 매핑 단계는 발행할 객체의 실제 직렬화보다 앞서 진행된다.
7. 라우팅 대상 결정
8. 메시지 브로커의 클라이언트는 메시지를 발행할 논리적 대상을 필요로 한다.
9. 이 대상은 일반적으로 물리적 인프라(토픽 또는 대기열)를 식별하며 이벤트 타입에서 정적으로 파생되는 경우가 많다.
10. @Externalized 어노테이션에 특별히 정의하지 않는한 기본적으로 appllication-local 타입 이름을 사용한다. 1. 즉 com.acme.app 기본 패키지가 있는 애플리케이션에서 com.acme.app.sample.SampleEvent는 sample.SampleEvent에 게시된다.
    • 일부 브로커는 실제 대상 내에서 다른 용도로 사용되는 다소 동적인 라우팅 키를 정의할 수도 있다.
      • 기본적으로는 라우팅 키는 사용되지 않는다.

Annotation-based Event Externalization Configuration

• 사용자 지정 라우팅 키를 정의하려면 $target::$key 패턴을 사용하면 된다.
  • CustomerCreated 이벤트는 메서드를 통해 고객의 lastName을 노출하고 있다.
  • 그리고 이를 @Externalized 어노테이션 내부 표현식에서 사용한다.

@Externalized("customer-created::#{#this.getLastname()}")
class CustomerCreated {
  fun getLastname(): String {
    // …
  }
}

• 키 계산이 복잡해진다면 이벤트를 파라미터로 받는 스프링 빈에 위임할 수도 있다.

@Externalized("…::#{@beanName.someMethod(#this)}")

Programmatic Event Externalization Configuration

• spring-modulith-events-api에는 위의 모든 단계를 사용자 정의할 수 있는 EventExternalizationConfiguration을 포함한다.

@Configuration
class ExternalizationConfiguration {

  @Bean
  fun eventExternalizationConfiguration(): EventExternalizationConfiguration {

    EventExternalizationConfiguration.externalizing()
      .select(EventExternalizationConfiguration.annotatedAsExternalized())
      .mapping(SomeEvent::class, it -> …)
      .routeKey(WithKeyProperty::class, WithKeyProperty::getKey)
      .build()
  }
}

Testing published events

• 스프링 모듈리스의 @ApplicationModuleTest를 사용하면 테스트 메서드에 발행된 이벤트 인스턴스를 주입할 수 있다.

@ApplicationModuleTest
class OrderIntegrationTests {
  @Test
  fun someTestMethod(events: PublishedEvents) {
    // …
    var matchingMapped = events.ofType(OrderCompleted::class)
      .matching(OrderCompleted::getOrderId, reference.getId())

    assertThat(matchingMapped).hasSize(1)
  }
}