CQRS
모놀리식 시스템의 단일 데이터베이스 환경은 데이터 쓰기와 조회가 함께 발생하여 조회 성능에 문제가 발생할 수 있다.
CQRS는 물리 노드를 분리해 데이터 쓰기 및 읽기에 대한 책임을 분할한다.
CQRS의 구현은 애플리케이션에 따라 간단하거나 매우 복잡할 수 있다.
구현 방법에 관계없이 CQRS는 항상 복잡성을 가져오므로 이 패턴으로 개발하는데 필요한 시나리오를 평가해야 한다.
CQRS 구현 장단점
장점
- 대기시간을 줄이기 위해 CommandStack(CUD)는 비동기식으로 큐에서 처리한다.
- 데이터를 쓰는 요청과 읽는 요청은 동일한 자원을 두고 경쟁하지 않는다.
- QyeryStack에 대한 쿼리는 별도로 독립적으로 수행되며 CommandStack 처리와 독립적이다.
- 비즈니스 의도 및 기타 DDD 개념에서 유비쿼터스 언어(보편 언어)를 사용한 도메인 표현
단점
- 구현의 어려움이 있다.
- 응용 개발자의 도메인 및 유비쿼터스 언어(보편 언어)에 대한 명확한 이해를 요구하며, 복잡도가 높다.
- 최종 일관성을 보장하기 위해 아키텍처 측면에서 심도있는 고려가 필요하다.
- 추가 솔루션을 도입할 경우 관리 요소 증가에 따른 유지보수 영역이 증가한다.
이벤트 소싱
기존 데이터베이스의 CUD는 기록과 결과를 각 Command 별로 로그를 기록함으로써 데이터를 추적하고 감시해왔다.
과정이 중요한 비즈니스의 경우 각 트랜잭션의 전체 과정을 기록하고 관리할 필요가 있으며,
우리는 이를 데이터 관점이 아닌 이벤트 관점에서 접근해 이벤트 소싱이라는 개념을 생성하게 되었다.
이벤트 소싱은 과거 기록을 관리할 수 있는 반면, 데이터베이스의 데이터가 기하급수적으로 증가할 수 있다.
이런 이유로 이벤트 소싱은 CQRS와 함께 사용되는 것이 일반적이다.
