기존의 영속화 방식의 경우, 클래스를 테이블에, 객체를 테이블 로우에 영속화 매핑하여 저장하게 된다. 오류가 발생한 경우, 추적이 매우 어렵다. 뿐만 아니라, 이후에 이벤트를 저장해야하는 경우에, 비즈니스 로직에 이벤트 발행 로직을 추가해야한다 (이는 더티 코드를 일으킬 수 있음). 정리해보자면 아래와 같은 문제가 생긴다.
• 객체-관계 임피던스 부정합(object-Relational impedance mismatch)2
• 애그리거트 이력이 없습니다.
• 감사 로깅을 구현하기가 번거롭고 에러가 잘 납니다.
• 이벤트 발행 로직이 비즈니스 로직에 추가됩니다....그렇다면 이벤트 소싱을 이용해보자.
이벤트 소싱
이벤트 소싱은 이벤트를 위주로 비즈니스 로직을 구현하고, 애그리거트를 DB에 일련의 이벤트로 저장하는 기법. 각 이벤트는 애그리거트의 상태 변화를 나타내며, 애그리거트의 비즈니스 로직은 이벤트를 생산/소비하는 요건 중심으로 구성된다.
-> 이벤트를 발행하는 형식으로, 비즈니스 로직을 구현하여 애그리거트 메서드의 관심사를 이벤트로 집중하게 만든다.
이벤트 소싱과 이벤트 발행
그렇다면, 이벤트 소싱을 하는 것은 좋으나, 이 이벤트가 발생한 후, 어떻게 다른 서비스에 이러한 이벤트가 발생했다는 것을 전달할까?
- 폴링 : DB에서 읽어 온 후, UPDATE한다
- 트랜잭션 로그 테일링을 통해 처리한다 (ex. DynamoDB Streams나 오픈소스를 통해)
이벤트 소싱의 특징
- 이벤트 소싱을 활용하는 경우, 스냅샷을 사용하여 성능을 개선할 수 있다.
- 멱등한 메시지 처리를 위해서는 RDBMS를 사용한는 방법, NoSQL에서는 가짜 이벤트를 생성하는 방법등이 있다.
- 도메인 이벤트를 발전시킬 수 있다. 대부분 하위 호환성이 보장된다. (이벤트명, 타입 변경과 같은 경우 제외)
이벤트 소싱 장점
• 도메인 이벤트를 확실하게 발행합니다.
• 애그리거트 이력이 보존됩니다.
• O/R 임피던스 불일치 문제를 대부분 방지할 수 있습니다.
• 개발자에게 타임 머신을 제공합니다.이벤트 소싱 단점
• 새로운 프로그래밍 모델을 배우는 데 시간이 걸립니다.
• 메시징 기반 애플리케이션은 복잡합니다.
• 이벤트를 개량하기가 까다로운 편입니다.
• 데이터를 삭제하기가 어렵습니다.
• 이벤트 저장소를 쿼리하기가 만만찮습니다.사가와 이벤트 소싱의 접목
오케스트레이션 사가를 보통 이벤트를 처음 생성하는 쪽에서 발행하고(1), 이를 통해 전파하는 방식을 취한다(2).
(1)
(2)
노력하는 사람