본문 바로가기
아키텍쳐를 고민하기

도메인 이벤트 기반 아키텍처의 이벤트란?

by simplify-len 2023. 8. 28.

 매주 일요일 밤 10시마다 지인과 함께 도메인 이벤트 기반 아키텍처를 이해하는 연습을 하고 있습니다.

 도메인 이벤트 기반 아키텍처을 이야기하면 대부분 Event Souring 과 CQRS 가 가장 먼저 언급되곤 합니다. 이 모든 단어의 한 가운데에 있는 것은 바로 이벤트입니다.

 아래는 과거에 작성했던 이벤트 관련 블로그 글입니다. 앞으로 이야기 할 부분에 대해서 관련있는 내용이라 읽기를 추천드립니다.

 

메세지와 이벤트의 차이점은 무엇인가?

들어가기 트레바리에서는 도메인주도설계를 실천하고 있습니다. 도메인주도설계라는 것은 말 그대로 도메인을 중심으로 복수의 도메인이 책임,역할, 협력을 할 수 있도록 개발하는 것을 말합

happy-coding-day.tistory.com

 

이벤트 스토어(?) 이벤트 소싱(?) 를 활용한 View 를 반복적으로 만들고 부수면서 느낀 점

결론부터 말씀드리면 '이벤트스토어를 활용해 내가 원하는 View 를 만들어 내기란 여전히 턱없이 내공이 부족하다.' 입니다. 먼저 이벤트스토어에 대한 이야기부터 해보려 합니다. 그 다음 반복

happy-coding-day.tistory.com

 

도메인 주도 설계에서의 이벤트

다시 돌아와서 우리가 일반적으로 이야기하는 이벤트는 어떤것 일까요? 도메인 이벤트란 무엇일까요? 앞에 언급한 이벤트를 살펴보면 도메인 주도 설계에서 사용되는 애그리게이트에서 어떤 사건에 대한 발생을 이벤트라고 지칭합니다.

그림 1 - 도메인 주도 설계에서의 도메인 이벤트

도메인 이벤트를 사용하는 주된 이유는 애그리게이트 간의 약한 결합을 유지시키면서 이벤트를 요청한 애그리게이트의 응집도를 높이기 위함입니다. 비동기 방식의 메세지 전달을 한 셈이 됩니다. 같은 맥락으로 API 도 앞서 언급한 도메인 이벤트와 동일하게 할 수 있다고 생각합니다. API 을 통한 메세지 전달은 동기식 방식이 될 것입니다.

우리가 흔히 알고 있는 도메인 이벤트는 '누군가가 관심있어라 하는 것.' 이라는 전제가 짙게 깔려 있습니다. 느슨한 의존 관계이던, 강한 의존 관계이던 의존 관계가 엮이게 됩니다.

 실무에서 좀 더 자세히 살펴보면요. 전 직장에서 이벤트 플랫폼을 구축하던 과정에서 이벤트의 발행 시점을 Aggregate 의 상태를 변경한 후에 이벤트를 발행했습니다. 코드로 살펴보면 아래와 같았습니다.

그림 2 - Dual Write

여기서 발생하는 주된 문제로 언급되는 부분은 Dual Write 문제이고, Aggregate 을 저장하는 값의 변경과 이벤트를 저장하는 이벤트 저장소 두 곳에 저장하면서 문제하게 되는데- 이건 도메인 주도 설계 관점에서의 도메인 이벤트에 대한 내용입니다.

이벤트 기반 아키텍처

그렇다면 도메인 이벤트 기반 아키텍처에서 이벤트는 무엇일까요? 동일한 걸까요? 결론부터 이야기하자면, 애그리게이트 간의 의존관계에 대한 강도가 도메인 주도 설계에서 말하는 이벤트의 의존관계 강도보다 더 낮다고 볼 수 있다고 생각합니다. 그렇게 생각하는 이유는 도메인 주도 설계에서는 애그리게이트의 상태가 변경되면, 애그리게이트를 저장하고 그 후에 도메인 이벤트를 Publish 하지만, 이벤트 기반 아키텍쳐에서는 도메인 이벤트만 발행합니다.

그림 3 - 일련의 도메인 이벤트 발행

여기서 발생되어진 이벤트는 추후 Foo 라는 Aggregate 를 '재구성'하기 위한 용도로 활용됩니다. 즉, 이벤트을 사용하는 주체가 다릅니다. 그러므로, 도메인 주도 설계에서 말하는 도메인 이벤트 보다는 약한 의존 관계를 가진다 라고 말할 수 있습니다.

 

댓글