등장 개념
-
명령 객체: 데이터를 변경하는 액션을 요청할 때 필요한 객체
(ex. CreateProduct, UpdateProduct, DeleteProduct 등)
-
도메인 이벤트: 명령의 결과, 주목할 만한 무언가가 발생했음을 알리는 역할
(ex. ProductCreated, ProductUpdated, ProductDeleted 등)
-
이벤트 스토어: 도메인 이벤트들이 순차적으로 저장되는 저장소, 레코드 추가만 가능한 특징이 있음
-
이벤트 소싱 패턴: 데이터의 현재 상태만 저장소에 저장하지 않고 추가적으로 이벤트만을 저장하는 저장소를 만들어 사용하는 패턴 (이벤트 스토어를 활용)
이벤트 소싱을 이용한 플로우
-
이벤트 소싱 장점
- 순차적 오퍼레이션들이 이벤트로 저장되어 도메인 객체(데이터)가 현재 상태가 되기까지의 과정이 기록으로 남음
- 이벤트 Replay를 하거나 Snapshot으로 과거의 데이터 상태로 돌아갈 수 있음 > 디버깅시 용이
- 먼저 이벤트들을 순차적으로 저장한 후, 동작은 후처리하는 방식을 통해 지연시간을 줄일 수 있음 -
이벤트 소싱 단점
- 기존 모델에 비해 더 많은 양의 데이터를 저장하기 때문에 대용량 처리에 대한 고려가 필요
- 이벤트 스토어가 생김으로 관리 요소가 증가함
- 상태 재현을 하기 위해 많은 양의 이벤트 재생이 필요할 수 있음(High Cost) > 스냅샷으로 극복 & 재현이 된다는 것은 장점
책에서 언급되었던 내용들
-
도메인 이벤트 네이밍은 보편 언어를 사용하고 과거형 동사 사용
- ProductCreated
- SprintScheduled
- BacklogItemPlanned
-
도메인 이벤트를 트리거시키는 두가지 일반적인 케이스
- 사용자 인터페이스(UI) 동작에 의한 이벤트 발생 (ex. PurchaseButtonClicked)
- 영업일 종료와 같은 시간 만료에 의해서 이벤트 발생 (ex. ProjectDateEnded)
-
도메인 이벤트의 인터페이스
- 순서가 중요하기 때문에 발생 시점 값은 필수적으로 가짐
- 이벤트를 이해하기 위한 적정량의 값들을 포함
- 지나치게 많은 값들을 포함하면 의미가 퇴색됨
- 지나치게 적은 프로퍼티를 가지면 추가적인 정보를 알기 위해서 추가 쿼리가 필요해질 수 있음
-
토론 주제
- 이벤트 소싱을 활용해 본 경험 (ex. 버전 관리 시스템)
- 이벤트 Replay, Snaphot 등을 결제 쪽에 적용하는 것이 도움이 될 수 있을지 아니면 관리 포인트가 너무 늘어나거나 현실적으로 이벤트를 쌓고 재현시키는 것이 어려운 것인지에 대해
-
기타 자료
- 이벤트 소싱 개념 강의
Deprecated