이벤트

시스템간 강결합에 의해 문제가 생기는 경우를 먼저보면

예를들어 쇼핑몰에서 사용자가 구매취소하면 환불처리해야하는데,

그림처럼 환불기능 실행 주체는 주문 도메인으로 잡았고 도메인 서비스를 주입하지않고 파라미터로 받아와서 주문상태를 변경하고 결재 상태를 변경하도록 코드를 짰다.

근데 이 코드엔 문제가 있다.

주문 도메인 객체에 환불 로직이 뒤섞여버리는 설계상의 문제가 있다.

또, 보통 결재의 경우 외부 API를 이용하는데 외부에 문제가 있어서 오작동한다면 트랜잭션은 어떻게 처리해야할지?,

외부 시스템의 성능이 느리다면 직접적인 영향을 받을수있는데 이건 어떻게 해야할지? 생각해봐야합니다.

트랜잭션의 경우 문제가 생기면 롤백하는 방법이 있겠지만

일딴 주문 취소한건 취소한거고 환불은 나중에 다시 처리하는 방법이 있을수도있다.

이런경우 이벤트를 사용할수있을것이다.

이벤트

---

이벤트 : 과거에 벌어진 어떤것 을 의미
예를틀어 사용자가 암호를 변경한것은 ‘암호를 변경했음 이벤트’, 주문을 취소했다면 ‘주문을 취소했음 이벤트’ 가 발생했다 라고 할수있음.

이벤트의 용도

1. 도메인의 상태가 바뀔 때 다른 후처리를 해야 할 경우 후처리를 실행하기 위한 트리거로 이벤트를 사용
2. 이벤트의 두 번째 용도는 서로 다른 시스템 간의 데이터 동기화

트리거의 역할

이벤트 생성 주체는 엔티티, VO, 도메인서비스같은 도메인계층에 있는 친구들이다.

이벤트 핸들러는 발생한 이벤트에 반응하는 친구들

예를들면 Order 모델에서 주문 취소를하면 ‘주문취소됨’ 이벤트가 발생하고 이벤트 디스패거처 OrderCanceledEventHandler가 작동해서 도메인 서비스인 RefundService가 작동하게 됨.

이벤트 장점

1. 도메인로직이 섞여있는것을 방지
2. 기능확장에 용이함

예를들면 구매 취소한 이후에 이메일 알림을 추가하고싶은경우 구매취소 로직을 수정하지않고 이메일 알림기능만 추가할수있다.

 

스프링이벤트를 사용하면 손쉽게 구현가능

 

참고로 이벤트 전달시 필요한 데이터만 전달하고 필요없는 데이터는 전달하지않는게 메모리상 좋다고함.