단순한 시스템은 상태 변경, 상태 조회가 동일한 모습 갖지만, 조금만 복잡해져도 상태 변경에 사용하는 데이터와 상태 조회 시 사용하는 데이터에 차이가 생긴다. 예를 들어 주문. 주문 생성 시 주문 ID, 회원 ID, 배송지 주소, 상품 ID 같은 데이터 사용한다. 반면 주문 정보 조회시에는 이들 정보 외에도 회원 이름, 상품명 같은 데이터 추가로 사용한다. 명령과 조회에서 사용하는 데이터가 서로 다른 것.
이렇게 명령과 조회가 서로 다른 데이터를 사용함에도 하나의 모델로 명령과 조회를 모두 구현하면 모델이 복잡해지고 유지보수가 어려워진다.
도메인이 복잡해질 경우 CQRS 패턴을 사용해서 이런 복잡도 문제 해결이 가능하다. CQRS는 Command Query Resoponsibility Segregation의 약자. 명령을 위한 모델과 조회를 위한 모델을 분리하는 패턴.
여기서 명령은 시스템의 상태를 변경하는 것. 조회는 상태를 조회하는 것.
CQRS는 명령 모델과 조회 모델 구분하므로 각 기능에 맞게 모델 구현가능한 이점 존재. 단일 모델 사용할 경우 조회 기능 때문에 명령 기능이 영향 받거나, 반대로 명령 기능때문에 조회 기능이 영향 받을 수 있다. CQRS는 이 두 모델 분리해 이련 문제 최소화함.
또한, 조회 모델 따로 존재하니 조회 성능 향상이 쉽다. 조회 모델에 캐시 적용하거나, 조회 전용 DB 확장하는 방식.
단점. 각 기능마다 모델 만들어야되서 코드 늘어남. 단순한 모델에 CQRS 도입시 작업량만 늘고 얻는 이점은 적을 수 있다.
다른 단점은 구현 기술이 늘어날 수있는것. 명령 모델과 조회 모델을 서로 다른 기술로 구현할 때 많은데, 특히 높은 트래픽을 처리하기위해 조회 모델을 별도 조회 전용 DB에 구축하는 경우 있다. 이경우 서로다른 DB 간 데이터 동기화 위해 추가적 메시징 수단을 도입해야한다.