CQRS 아는 척 해보기 ( 기본 개념 )

https://www.youtube.com/watch?v=xf0kXMTFJm8&list=PLwouWTPuIjUgr29uSrSkVo8PRmem6HRDE&index=5

 

 

 

- CQRS

Command Query Reponsibility Segregation

CQRS란 시스템 데이터를 변경하는 역할인 '명령' 과 시스템 데이터를 조회하는 역할인 '쿼리'를

구성하는 요소를 나누는 것을 의미한다.

 

코드만 나누는 게 아닌 구현 방식이나 시스템 규모에 따라서 DB, 프로세스 등도 나눕니다.

 

 

- 좋은 이유는?

사진만으로 봤을때는 하는 이유를 즉시 파악하기 불가능하다.

왜냐하면 다루고 있는 구성요소 (Member) 의 데이터가 별반 차이가 없기 때문이다.

그래서 굳이 코드를 한번 더 작성하는 느낌도 있고, 개발이 느려지는 느낌을 받을 수 있다.

 

만약 명령과 조회에 대해서 단일 모델을 사용한다면?

기능 마다 구성요소에 사용해야 할 필드가 지속적으로 추가될 것입니다.

 

이런식으로 만들게 되면 Member는 역할이 엄청나게 분산될 것이고

필요하지 않는 부분에서 해당 구성요소를 불러오는 일이 생기게 될것이다.

즉, 역할과 책임이 모호해지고, 가독성도 좋지 않으며, 유지보수에 대한 처리가 힘들어질것이다.

 

왜 이런 문제가 생길까?

 

가장 큰 이유는

첫번째, 명령과 쿼리가 다루는 데이터가 다르기 때문이다.

명령은 한 영역의 데이터만을 다루겠지만,  쿼리는 아니다.

쿼리는 여러 영역의 데이터를 다루는 경향이 있다.

 

JPA를 예시로 볼때, 명령을 예시로 든다면 주문을 하는 경우 Order 만 관여하면 되겠지만

상품조회 및 회원조회 같은 쿼리의 경우 Order 뿐만 아니라 User, Item 등의 영역에 뛰어들수 밖에 없다.

 

애초에 단순한 시스템이 아닌이상 명령과 쿼리를 같은 모델에 담을 수 없다.

 

두번쨰, 코드 변경 빈도 및 사용자의 다름.

세번째, 기능마다 성능 요구가 다름

 

그래서 명령과 쿼리를 분리시켜야 함.

명령과 쿼리를 위한 모델을 분리하면 앞에서 언급했던 문제들이 줄어들게 됨

 

만약 모델의 모호함이 없어지게 된다면 ?

1. 명령영역의 모델과 쿼리영역의 모델이 무엇을 표현하고 있는지가 명확해짐

2. 전반적인 코드 가독성과 유지보수성이 좋아질 가능성이 높아진다

3. 쿼리 쪽은 캐쉬를 적용하고 명령 쪽은 비동기를 적용하는 식으로 기능에 따라서

   성능향상 기법을 다르게 적용하는 것도 용이해진다.