동기

최근에 DDD 를 학습하면서 도메인 이벤트라는 것을 알게 되었다.

그러면서 Spring 에서 한 VM 안에서 이벤트를 발행하고 해당 이벤트를 handling 하는 코드를 접했고, 그와 관련해서 여러 실습을 해보던 중 Spring 에서 무언가 Magic 이 일어나고 있는것 같은 느낌을 받았다.

긴 말 필요 없이 아래의 코드를 확인해보자.

@Entity(name = "orders")
public class Order {

    public static Order create() {
        return new Order();
    }

    @Id
    private Long id;
    private OrderStatus status = CREATED;

    public void cancel() {
        OrderCanceled event = OrderCanceled.of(id);
        Events.raise(event); // event trigger
        status = CANCELED;
    }
}

위의 코드는 Order 라는 실습을 위해 탄생한 가상의 도메인이다.

실습의 시나리오에서는 아주 간단한 로직만을 가지고 있다.

주문이 취소되면 Membership 의 상태를 변경하는 것이 다다.

해당 Order 라는 가상의 도메인 코드에서 집중해야 할 부분은 cancel() 이라는 메서드가 하는 일이다.

Events 라는 유틸리티성 클래스의 static 메서드인 raise() 를 호출해서 이벤트를 발행한다.

Events 클래스를 확인해보자

public class Events {
    private static ApplicationEventPublisher publisher;

    protected static void setPublisher(ApplicationEventPublisher publisher) {
        Events.publisher = publisher; // initializing
    }

    public static void raise(DomainEvent event) {
        if (publisher == null) {
            throw new IllegalStateException();
        }
        publisher.publishEvent(event);
    }
}

Events 클래스는 Spring 의 EventDispatcher 인 ApplicationEventPublisher 를 감싸고 있는 일종의 Facade 역할을 수행한다.

해당 코드에서는 raise() 를 호출하게 된다면 멤버로 가지고 있는 ApplicationEventPublisher 와 협력하여 event 를 publish 한다.

ApplicationEventPublisher 는 스프링에서 제공하는 event publisher 인데, Events 라는 클래스에서는 사용성을 높이기 위해서 static 으로 EventPublisher 를 외부에서 주입받는다.

@Configuration
@RequiredArgsConstructor
public class EventsConfig {
    private final ApplicationContext applicationContext;

    @Bean
    public InitializingBean eventsInitializer() {
        return () -> Events.setPublisher(applicationContext);
    }
}

Events 를 초기화 하기 위해서 InitializingBean 을 사용했다.

자.

이런 저런 과정들을 해주고 해당 이벤트를 받고 있는 event handler 로 가보자

@Service
@RequiredArgsConstructor
@Slf4j
public class OrderCanceledEventHandler {
    private final MembershipTerminateService membershipTerminateService;

    @EventListener(OrderCanceled.class)
    public void handle(OrderCanceled event) {
        log.info("OrderCanceledEvent occurred !! => {}", event);
        membershipTerminateService.terminateBy(event.getOrderId());
    }
}

@EventListener 어노테이션을 추가하면 해당 이벤트가 발행될 때 Listening 하여 특정 로직을 수행할 수 있도록 한다.

어떠한 마법이 숨어있는 것일까?

There is No Magic in spring

늘 그렇듯 There is No Magic in spring 이다.

내가 궁금한 것은 우선

왜 Config 에서 ApplicationContext 를 Events 에게 set 하는가?
@EventListener 는 어떻게 consuming 하는가

인데, 하나씩 확인해보자.

왜 Config 에서 ApplicationContext 를 Events 에게 set 하는가?

EventPublisher 를 동적으로 set 해주는 Config 코드에서 ApplicationContext 를 넘겨서 Events 클래스에게 ApplicationEventPublisher 를 설정해준다.

@Configuration
@RequiredArgsConstructor
public class EventsConfig {
    private final ApplicationContext applicationContext;

    @Bean
    public InitializingBean eventsInitializer() {
        return () -> Events.setPublisher(applicationContext);
    }
}

Events 가 원하는 멤버는 ApplicationEventPublisher 인데 왜 ApplicationContext 를 넘길까?

public class Events {
    private static ApplicationEventPublisher publisher;

    protected static void setPublisher(ApplicationEventPublisher publisher) {
        Events.publisher = publisher;
    }

    public static void raise(DomainEvent event) {
        //...
    }
}

우리가 알고 있는 ApplicationContext 는 IoC Container 로서 Bean Factory 역할을 수행한다.

그런 ApplicationContext 에는 다양한 기능이 존재하는데, 그중 하나가 바로 ApplicationEventPublishing 이다.

실제 스프링의 코드를 확인하더라도 동일하다

그리고 해당 ApplicationEventPublisher 의 구현은 ApplicationContext 를 상속하고 있는 AbstractApplicationContext 에서 존재한다.

결국 Events 에게 raise() 라는 협력을 요청하게 되면 AbstractApplicationContext 에 존재하는 publishEvent() 가 호출되게 된다.

Event 가 Publish 되면 Spring 에서 제공하는 ApplicationEvent 타입인지 먼저 확인하고 그렇지 않다면, Custom 한 Event 라면 ApplicationEvent 의 구현체인 PayloadApplicationEvent 로 변환한다.