최범균님의 CQRS 아는척하기를 적극적으로 참고했습니다!
Command and Query Responsibility Segregation
- Command와 Query의 책임을 분리하는 패턴
- 명령(시스템 데이터 변경)역할을 수행하는 구성 요소와 쿼리(시스템 데이터 조회)역할을 수행하는 구성요소를 나누는 것
🏷️ 코드가 중복되고, 개발이 느려지는 느낌인데 왜 사용하는지?
✔️ 만약 명령과 조회에 단일 모델을 사용하게되면?
- 코드의 역할, 책임이 모호해진다
- 의미/가독성이 나빠지고, 유지보수성이 떨어진다.
- 명령에 필요한 데이터와 쿼리에 필요한 데이터가 다르다.
예시) 이름변경 기능은 Member 테이블에 해당하는 데이터만 가져와서 Member 객체를 생성하지만, 주문목록 조회 기능에서는 최소 2,3개의 테이블을 이용하여 Member 객체를 생성하게 된다.
✔️ 기능마다 트래픽 패턴, 성능 요구사항이 다르다.
- 사용자의 상품 목록 조회, 상품 상세 조회 기능 -> 조회 속도가 느리면 판매율에 영향이 있음
- 백오피스의 판매 수치 조회 기능 -> 조회 속도 느리다고 판매율에 영향을 주지 않음
🏷️ 구조
✔️ 같은 프로세스, 같은 DB
✔️ 같은 프로세스, 다른 DB, 다른 테이블
✔️ 같은 프로세스, 다른 DB
✔️ 다른 프로세스, 다른 DB
🏷️ 장단점
✔️ 장점
- 도메인 자체에 집중할 수 있게된다.
- 조회 성능을 향상시킬 수 있다.
- 데이터소스의 크기 조정이 가능하다 -> 조회 작업 비율이 훨씬 높기 때문에 조회 인스턴스에 더 높은 투자를 할 수 있다.
- R과 CUD를 분리함으로써 과도하게 복잡한 모델을 덜 복잡하게 만듦으로서 시스템 복잡도를 줄일 수 있다.
✔️ 단점
- 일시적으로 데이터의 일관성이 보장되지 않을 수 있다.
- 서비스 개발 복잡성이 올라간다.
[참고자료]
코딩하는 돌멩이 👻