「도메인 주도 개발 시작하기」10장 이벤트 정리

🎈 10.1. 시스템 간 강결합 문제

쇼핑몰에서 구매 후 취소를 하면 환불되어야 하는 상황.

도메인 객체에 서비스를 파라미터로 전달하는 상황.

보통 결제 시스템이 외부에 존재하므로 RefundService는 외부에 있는 결제 시스템이 제공하는 환불 서비스를 호출함. 

//도메인 서비스를 파라미터로 받는 경우
public class Order{
	public void cancel(RefundService refundService){
    	//주문 로직
    	verifyNotYetShipped();
        this.state = OrderState.CANCELED;
        
        //결제 로직
        this.refundStatus = State.REFUND_STARTED;
        try{
        	refundService.refund(getPaymendId());
            this.refundStatus = State.REFUND_COMPLETED;
        } catch(Exception ex){
        	???
        }
    }
    ...

 

//응용 서비스에서 환불 기능을 수행하는 경우
public class CancelOrderService{
	private RefundService refundService;
    
    @Transactional
    public void cancel(OrderNo orderNo){
    	Order order = findOrder(orderNo);
        order.cancel();
        
        order.refundStarted();
        try{
		refundService.refund(order.getPaymentId());
		order.refundCompleted();
        } catch(Exception e){
        	???
        }
    }
    
    ...

문제 1. 외부 서비스가 정상이 아닐 경우 트랜잭션 처리를 어떻게 해야 하는가?

문제 2. 외부 서비스 성능에 직접적인 영향을 받게 됨.

문제 3. Order는 주문을 표현하는 객체인데 결제 도메인의 환불 관련 로직과 뒤섞이게 됨. 환불 기능이 바뀌면 Order도 영향을 받음을 의미 -> 주문 도메인 객체의 코드를 결제 도메인 때문에 변경할지도 모르는 상황은 좋지 않음

문제 4. 기능을 추가할 때 로직이 섞이고 트랜잭션 처리가 더 복잡해지는 문제가 발생함. 

 

이러한 문제들은 주문 바운디드 컨텍스트와 결제 바운디드 컨텍스트 간의 강결합 high coupling 때문이다. 

주문이 결제와 강하게 결합되어 있어 주문 바운디드 컨텍스트가 결제 바운디드 컨텍스트에 영향을 받음.

 

이런 강한 결합을 없애는 방법: 이벤트. 

특히 비동기 이벤트를 사용하면 두 시스템 간의 결합을 크게 낮출 수 있음.

 

🎈 10.2. 이벤트 개요

이벤트: '과거에 벌어진 어떤 것'

10.2.1 이벤트 관련 구성 요소

도멘인 모델에 이벤트를 도입하려면 이벤트의 구성요소인 이벤트, 이벤트 생성 주체, 이벤트 디스패처(퍼블리셔), 이번트 핸들러(구독자)를 구현해야 함. 

이벤트 생성 주체: 엔티티, 밸류, 도메인 서비스와 같은 도메인 객체. 도메인 객체는 도메인 로직을 실행해서 상태가 바뀌면 관련 이벤트를 발생시킴. 

이벤트 핸들러: 이벤트 생성 주체가 발생한 이벤트에 반응. 예를 들어 '주문 취소됨 이벤트'를 받는 이벤트 핸들러는 해당 주문의 주만자에게 SMS로 주문 취소 사실을 통지. 

이벤트 디스패처: 이벤트 생성 주체와 이벤트 핸들러를 연결해 주는 것. 

 

10.2.2 이벤트의 구성

예) 배송지 변경할 때 발생하는 이벤트

이벤트를 위한 클래스. 이벤트는 현재 기준으로 과거에 벌어진 것이므로 이름에 과거 시제 사용함. 

public class ShippingInfoChangedEvnet{
	private String orderNumber;
    private long timestamp;
    private ShippingInfo newShippingInfo;
    
    //생성자, getter
}

 

이벤트를 발생하는 주체는 Order 애그리거트. 

public class Order {
	public void changeShippingInfo(ShippingInfo newShippingInfo){
    	verifyNotYerShipped();
        setShippingInfo(newShippingInfo);
        Events.raise(new ShippingInfoChangedEvent(number, newShippingInfo));
    }
    
    ...
}

 

10.2.3 이벤트 용도

첫 번째: 트리거. 도메인의 상태가 바뀔 때 다른 후처리가 필요하면 후처리를 실행하기 위한 트리거로 이벤트를 사용할 수 있음. 

두 번째: 서로 다른 시스템 간의 데이터 동기화. ex) 배송지를 변경하면 외부 배송 서비스에 바뀐 배송지 정보를 전송해야 함. 

 

10.2.4 이벤트 장점

서로 다른 도메인 로직이 섞이는 것을 방지할 수 있음. 

 

🎈 10.3 이벤트, 핸들러, 디스패처 구현

10.3.1 이벤트 클래스

이벤트 자체를 위한 상위 타입은 존재하지 않고 원하는 클래스를 이벤트로 사용하면 됨. 이름에 과거 시제를 사용해야 한다는 점만 유의. 

이벤트 클래스는 이벤트를 처리하는데 필요한 최소한의 데이터를 포함해야 함. 

 

10.3.2 Events 클래스와 ApplicationEventPublisher

이벤트 발생과 출판을 위해 스프링이 제공하는 ApplicationEventPublisher를 사용함. 

import org.springframework.context.ApplicationEventPublisher;

public class Events {
	private static ApplicationEventPublisher publisher;
    
    static void setPublisher(ApplicationEventPublisher publisher) {
    	Events.publisher = publisher;
    }
    
    public static void raise(Object event){
    	if(publisher != null){
        	publisher.publishEvent(event);
        }
    }
}

 

10.3.3 이벤트 발생과 이벤트 핸들러

이벤트 핸들러는 스프링이 제공하는 @EventListener 애너테이션으로 구현함. 

@Service
public class OrderCanceledEventHandler {
	private RefundService refundService;
    
    public OrderCanceledEventHandler(RefundService refundService) {
    	this.refundService = refundService;
    }
    
    @EventListener(OrderCanceledEvent.class)
    public void handle(OrderCanceledEvent event){
    	refundService.refund(event.getOrderNumber());
    }
}

 

10.3.4 흐름 정리

1. 도메인 기능 실행.

2. 도메인 기능을 Events.raise()를 이용해 이벤트를 발생시킴. 

3. Events.rais()는 스프링이 제공하는 ApplicationEventPublisher를 이용해 이벤트 출판. 

4. ApplicationEventPublisher는 @EventListener(이벤트타입.class) 애너테이션이 붙은 메서드를 찾아 실행한다. 

 

🎈 10.4. 동기 이벤트 처리 문제

이벤트 사용해서 강결합 문제 해소함. 외부 서비스에 영향을 받는 문제가 남아 있음. 

//1. 응용 서비스 코드
@Transactional
public void cancel(OrderNo orderNo) {
	Order order = findOrder(orderNo);
    order.cancel(); //order.cancle()에서 OrderCanceledEvent 발생
}

//2. 이벤트를 처리하는 코드
@Service
public class OrderCanceledEventHandler {
	...생략
    
    @EventListener(OrderCanceledEvent.class)
    public void handle(OrderCanceledEvent event) {
    	//외부 환불 서비스와 연결된
    	//refundService.refund()가 느려지거나 익셉션이 발생하면?
        refundService.refund(event.getOrderNumber());
    }
}

시스템 성능 저하 뿐만 아니라 트랜잭션도 문제. 

트랜잭션을 롤백 해야 할까? 트랜잭션을 롤백 하면 루매 취소 기능을 롤백 하는 것이므로 구매 취소가 실패하는 것과 같음. 

외부 시스템과의 연동을 동기로 처리할 때 발생하는 성능과 트랜잭션 범위 문제를 해소하는 방법은

1. 이벤트를 비동기로 처리하거나

2. 이벤트와 트랜잭션을 연계하는 것. 

 

🎈 10.5. 비동기 이벤트 처리

'A하면 이어서 B하라'는 내용을 담고 있는 요구사항은 실제로 'A 하면 최대 언제까지 B 하라'인 경우가 많음.

ex) 이메일 인증, 주문 취소 후 결제 취소 등

요구사항은 이벤트를 비동기로 처리하는 방식으로 구현할 수 있음. 즉 A 이벤트가 발생하면 별도 스레드로 B를 수행하는 핸들러를 실행하는 방식으로 요구사항을 구현.

 

다양한 이벤트 비동기 구현 방법 중 다음 네 가지를 알아봄. 

1. 로컬 핸들러를 비동기로 실행하기

2. 메시지 큐를 사용하기

3. 이벤트 저장소와 이벤트 포워더 사용하기

4. 이벤트 저장소와 이벤트 제공 API 사용하기

 

10.5.1 로컬 핸들러 비동기 실행

스프링의 @Async 애너테이션으로 손쉽게 비동기로 이벤트 핸들러 실행할 수 있다. 

- @EnabledAsync 애너테이션을 사용해서 비동기 기능을 활성화한다. 

- 이벤트 핸들러 메서드에 @Async 애너테이션을 붙인다. 

 

10.5.2 메시징 시스템을 이용한 비동기 구현

카프카나 래빗MQ와 같은 메시징 시스템을 사용하는 것. 

이벤트가 발생하면 이벤트 디스패처는 이벤트를 메시지 큐에 보냄. 

메시지 큐는 이벤트를 메시지 리스너에 전달하고, 메시지 리스너는 알맞은 이벤트 핸들러 이용해 이벤트 처리. 

 

이벤트를 메시지 큐에 저장하는 과정과 메시지 큐에서 이벤트를 읽어와 처리하는 과정은 별도 스레드나 프로세스로 처리됨. 

 

 

 

10.5.3 이벤트 저장소를 이용한 비동기 처리

이벤트가 발생하면 핸들러는 스토리지에 이벤트를 저장함. 

포워더는 주기적으로 이벤트 저장소에서 이벤트를 가져와 이벤트 핸들러를 실행함. 

포워더는 별도 스레드를 이용하기 때문에 이벤트 발행과 처리가 비동기로 처리됨. 

이벤트 저장소와 포워더를 이용한 비동기 처리

API를 이용해서 이벤트를 외부에 제공하는 방식

포워더 방식이 포워더를 이용해서 이벤트를 외부에 전달한다면, API 방식은 외부 핸들러가 API 서버를 통해 이벤트 목록을 가져감. API 방식에서는 이벤트 목록을 요구하는 외부 핸들러가 자신이 어디까지 이벤트를 처리했는지 기억해야 함. 

 

이벤트 저장소 구현

- EventEntry: 이벤트 저장소에 보관할 데이터. EventEntry는 이벤트를 식별하기 위한 id, 이벤트 타입인 type, 직렬화한 데이터 형식인 contentType, 이벤트 데이터 자체인 payload, 이벤트 시간인 timestamp를 갖는다. 

- EventStore: 이벤트를 저장하고 조회하는 인터페이스를 제공

- JdbcEventStore: JDBC를 이용한 EventStore 구현 클래스.

- EventApi: REST API를 이용해서 이벤트 목록을 제공하는 컨트롤러. 

 

REST API 구현

offset과 limit 파라미터를 이용하는 REST API를 스프링 MVC 컨트롤러를 이용해 구현함. 

 

포워더 구현

스프링의 @Scheduled 애너테이션 혹은 별도 스케줄링 프레임워크를 이용해 메서드를 주기적으로 실행. 

 

🎈 10.6. 이벤트 적용 시 추가 고려 사항

1. 이벤트 소스를 EventEntry에 추가할지 여부

2. 포워더에서 전송 실패를 얼마나 허용할 것이냐에 대한 것

3. 이벤트 손실에 대한 것

4. 이벤트 순서

5. 이벤트 재처리

 

10.6.1 이벤트 처리와 DB 트랜잭션 고려

이벤트 처리를 동기를 하든 비동기로 하든 이벤트 처리 실패와 트랜잭션 실패를 함께 고려해야 함. 트랜잭션이 성공할 때만 이벤트 핸들러를 실행하면 고려해야 할 사항이 덜 복잡해진다. 

스프링의 @TransactionalEventListener 애너테이션은 스프링 트랜잭션 상태에 따라 이벤트 핸들러를 실행할 수 있게 함.