CQS는 뭐고? 더 나아가 CQRS 뭘까?

[Seungpang]

주제

CQS는 뭐고? 더 나아가 CQRS 뭘까?

선정 이유

4가지 원칙과 기법에서 디비터의 법칙, 묻지 말고 시켜라는 많이 들어보기도 하고 연습을 했는데 의도를 드러내는 인터페이스 또는 명령-쿼리 분리는 잘 들어보지 못해서 찾아봤는데

Bertrand Meyer가 말하는 CQS는 ‘시스템의 상태를 바꾸는지’를 기준으로 함수를 크게 두 가지로 분류한다.

Command:

• 결과를 반환하지 않고, 대신 시스템의 상태를 변화시킨다

Query:

• 결과값을 반환하고, 시스템의 관찰가능한 상태를 변화시키지 않는다. 따라서 부작용에서 자유롭다

CQRS

CQRS를 명령(시스템 데이터 변경) 역할을 수행하는 구성 요소와 쿼리(시스템 데이터 조회) 역할을 수행하는 구성 요소를 나누는 것이 CQRS

구현: 같은 프로세스, 같은 DB

• 가장 단순
• 명령/쿼리 동일 데이터 보장

구현: 같은 프로세스, 같은 DB, 다른 테이블

• 쿼리 전용 테이블 사용
  • 예: 최근 조회수 많은 글 목록
• 명령이 쿼리 전용 데이터 변경 유발

구현: 같은 프로세스, 다른 DB

• 상품목록을 레디스와 같은 저장소에 캐싱하고 쿼리 모델은 레디스를 사용
• 명령이 데이터를 변경하면 쿼리쪽 db에 전달

구현: 다른 프로세스, 다른 DB

• 마이크로 서비스

명령(시스템 데이터 변경) 역할을 수행하는 구성 요소와 쿼리(시스템 데이터 조회)역할을 수행하는 구성 요소를 나누는 것이 CQRS

• 명령과 쿼리는 다루는 데이터가 다름
• 명령과 쿼리는 코드 변경 빈도/사용자가 다름
• 기능마다 성능 요구가 다름

관련 페이지

202p ~ 213p 마틴 파울러 글

[Seungpang]

• CQS: 객체1개에서 퍼블릭 인터페이스를 제공함에 있어 명령과 쿼리를 구분

• CQRS: 명령을 담당하는 객체와 쿼리를 담당하는 객체를 구분

• CQS, CQRS의 공통적인 장점은 가독성이 좋아진다.

  • CQRS의 장점은 무엇?
    • 각각의 도메인 목적에 맞게 집중하여 개발
    • 명령과 쿼리 파이프라인을 원하는대로 최적화하면서 다른 요소가 깨질 위험이 없다
  • 단점
    • 구현해야 할 코드가 더 많다.
    • 유지 비용 증가
    • 더 많은 구현 기술이 필요

• 만약 업데이트가 빈번하다면 데이터 전파하는 과정에서 문제가 있지 않나?

  • 실시간 업데이트가 필요한 시스템에는 적합하지 않다.