도메인 모델 패턴, 이벤트 소싱 도메인 모델 패턴 ⇒ 애그리게이트의 상태를 저장하는 방식이 다르다.
이벤트 소싱
테이블을 보면 일반적으로 순서도는 필요 없게 된다.
name status
| A | new_lead |
| B | closed |
| c | new_lead |
현재 상태를 문서화하지만 각 리드가 현재 상태에 도달한 이력을 알 수가 없다. ⇒ 현재 상태만 알 수 있다.
- 이벤트 소싱 패턴은 데이터 모델에 시간 차원을 도입한다.
name status timestamp
| A | closed | … |
| A | new_lead | … |
| B | closed | … |
| c | new_lead | … |
- history를 통해서 프로젝션(원하는 시점의 데이터 추출) 할 수 있다.
- 버전을 적어 활용할 수도 있다.
- 검색이 유용하다
- 변경사항을 인지하지 못할 경우 이벤트 소싱을 사용하면 과거 정보를 쉽게 프로젝션 가능
- 분석하기 편하다
- 모델을 사용하여 영업 프로세스를 최적화 할 수 있다.
이벤트 스토어
모든 변경사항이 이벤트로 저장하고 있는 데이터베이스 ⇒ 추가만 가능(삭제, 수정 불가능)
- history 테이블 ⇒ kafka를 통해서 이벤트 발생시키고 서비스하는 DB 말고 다른 DB에 저장할 수 있지 않을까?
이벤트 소싱 도메인 모델
이벤트 소싱이 아닌 이벤트 소싱 도메인 모델인 이유? ⇒ 애그리게이트의 수명주기 변경을 나타내기위해 이벤트 소싱을 사용하기때문에
애그리게이트에 대한 각 작업
- 도메인 이벤트 로드
- 상태 표현을 재구성
- 새로운 도메인 이벤트 생성
- 이벤트 스토어에 커밋
장점
- 시간 여행
- 과거 이력을 알 수 있고 과거 상태를 복원할 수도 있다.
- 통찰력
- 다른 상태 표현 방식으로 변환할 수 있는 유연한 모델 제공
- 감사 로그
- 금전 거래를 관리하는 시스템(증권?)에 잘 이용
- 낙관적 동시성 제어
- 이벤트를 통해 관리
단점
- 학습 곡선
- 경험이 없다면 시간이 필요
- 모델의 진화
- 발전 시키는게 어려울 수 있다. (스키마를 조정해야하는 경우 어려움)
- 복잡성
- 설계가 복잡해진다.
성능
- 시스템 성능에 부정적이 영향을 줄 수 있다.
- 엄청난 양의 데이터 생성
- 확장성 고려해야한다.
'책 > 도메인 주도 설계 첫걸음' 카테고리의 다른 글
| 커뮤니케이션 패턴 (0) | 2023.02.28 |
|---|---|
| 아키텍처 패턴 (0) | 2023.02.28 |
| 간단한 비즈니스 로직 구현과 복잡한 비즈니스 로직 다루기 (0) | 2023.02.28 |
| 바운디드 컨텍스트 연동 (0) | 2023.02.28 |
| 도메인 복잡성 관리 (1) | 2023.02.28 |