3 asked

1

안녕하세요, 이도원입니다.

CQRS와 Event Sourcing을 함께 사용할 때, RDS에 직접 데이터를 저장하고 읽어오는 방식은 Command 영역과 Query 영역의 역할에 따라 다릅니다. 일반적인 관계형 데이터베이스(RDS) 테이블은 여전히 사용되지만, 그 역할과 구조가 이벤트 소싱 모델에 맞게 변형됩니다. 결론적으로, 데이터는 말씀하신 ORDER_EVENT 와 같은 이벤트 테이블이 맡게 됩니다. Command 이벤트의 모든 데이터 변경은 말씀하신 것처럼 이벤트 형태로 저장됩니다. 쓰기 영역에 새로운 이벤트가 저장되면, 이 이벤트를 구독하는 프로젝션(Projection) 또는 리스너가 동작하여 Query 영역에서는 사용 됩니다. CQRS+Event Sourcing 기반에서는 데이터의 최종 상태(Current State)를 저장하는 기존 방식의 정규화된 RDS 테이블은 Command 영역에서 사용되지 않습니다.

추가 문의사항 있으시면 다시 글 남겨주시기 바랍니다.

감사합니다.

0

안녕하세요, 미니리님. 인프런 AI 인턴입니다.

질문해주신 내용을 바탕으로, 관련 자료를 조사해본 결과를 안내드리겠습니다.

마이크로서비스 아키텍처에서는, 특히 Event Sourcing 패턴을 사용할 경우, 이벤트가 비즈니스 상태 변경을 기록하는데 사용됩니다. 이와 반해, Query는 최종 상태를 읽기 위해 이벤트 소스를 리플레이하여 현재 상태를 재구축합니다. 이 방식의 장점은 비즈니스 로직의 병합이나 마이크로서비스 간의 동기화를 용이하게 한다는 점입니다.

이벤트 소싱을 도입할 때, 이벤트가 기록되는 테이블(예: ORDERS_EVENT)와 최종적인 데이터를 저장하는 테이블(예: ORDERS 혹은 ORDERS_VIEW)이 분리될 수 있습니다. 이벤트가 기록되는 테이블에는 모든 비즈니스 이벤트가 타임라인 순으로 저장되지만, 실제 조회 세션에서 사용되지 않을 수는 없습니다. 여러 접근 방식 중 어떤 모델을 사용할지는 아키텍쳐의 설계와 요구사항에 따라 다를 수 있습니다.

예를 들어, ORDERS 테이블은 최종 상태만 저장하는 Read Model로 쓰일 수 있으며, 이벤트들은 ORDERS_EVENT 테이블에서 관리되면서 비즈니스 로직의 변화를 추적합니다.

더 구체적이고 상세한 이해를 원하신다면, Event Sourcing 관련 질문 - 이벤트 저장소 및 최종 상태 관리을 확인하시면 좋습니다. 이 게시물에서 Event Sourcing과 관련된 다양한 패턴과 설계 접근 방법에 대해 설명하고 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.