CQRS 패턴

김성지·2023년 4월 13일

그냥공부

목록 보기

9/10

CQRS

Command Query Responsibility Segregation 의 약자이다.
명령과 조회 라는 책임으로 분리하겠다는 뜻
CRUD의 CUD가 명령에 해당하고
R는 조회에 해당

Command

Command는 시스템에 어떠한 side effect가 발생하는 것
즉 변경을 가하는 행위이다.

Query

Query는 시스템의 상태를 관찰할 수 있는 행위를 말한다.
Query성 함수라하면 시스템의 상태만 확인하는 함수이다.
시스템의 상태를 단지 반환하기만 하고 상태를 변경시키지 않아야 함

CQS

버트란드 마이어씨가 Command와 Query를 분리해야 하며
하나의 함수는 둘 중 하나의 성격만 띄어야 한다고 했다.

만약 하나의 함수에서 Command 와 Query가 모두 동시에 일어나게 된다면... 이는 소프트웨어의 3가지 원칙 중 복잡하지 않아야 한다는 KISS 원칙이 지켜지지 않다는 것을 의미

CQRS

CQRS는 Greg Young이 소개한 말이고, CQS에 비해 조금 더 큰 레벨에서의 Command 모듈과 Query 모듈의 책임을 분리하자는 의도이다.

CQS는 코드레벨에서의 분리를 말한다면
CQRS는 조금 더 거시적인 관점에서의 분리를 의미한다.

Service interface에서
Read side와 Write side가 존재한다.
db도 각각 하나씩 붙어있다

분리하게 된 이유

애플리케이션이 데이터를 다루는데 있어서는 특정 모델로써 다루어진다고 한다.
(예를 들어 "구매 내역" 이라는 데이터는 애플리케이션 내에서
구매자,구매일시,결제금액... 등의 속성을 지니는 PurchaseHistory.class 모델로써 다뤄진다.)

근데 이러한 모델을 애플리케이션이 변화하면서 점점 그 형태가 매우 이상해질 수 있다고 한다. 예를 들어서 구매시 사용한 쿠폰을 기록하기 위해 PurchaseHistory.class에 "usedCoupon" 같은 게 점점 추가가 되면서
시간의 흐름에 따라 다양한 요구사항을 녹여내려다 보니.. 초기 모델보다 거대해지면서 의도와는 다른 모델이 될 수 있다.

이러한 변질된 모델을 이용하여 데이터를 사용하게되면 문제가 발생한다.
(요청에 불필요한 데이터를 재가공하여 사용,모델의 복잡도 증가 등등..)

이러한 흐름에서 확인해보니, 대부분의 정책이나 제약은 데이터변경에서 처리되고, 데이터 조회작업은 단순 데이터 조회라서

실질적으로 데이터를 저장,갱신,삭제에 필요한 모델과
조회하여 사용하는 모델

두가지의 모델로 분리하여 관리하는 방법을 생각해 냈다고 한다.

이것이 CQRS가 등장하게 된 배경이당.

CQRS는 언제 도입해야 할 까

UX와 비즈니스 요구사항이 복잡해질 때
조회 성능을 보다 높이고 싶을 때
데이터를 관리하는 영역과 이를 뷰로 전달하는 영역의 책임이 나뉘어야 할 때
(서로의 책임이 분명해져야 할 때 ex) 명령 모델을 주로 이용하는 팀과 조회 모델을 주로 이용하는 팀이 나뉘어있을 때)
시스템 확장성을 높이고 싶을 때