11.1 단일 모델의 단점

조회 화면에 필요한 여러 애그리커트를 조회하기 위해 식별자로 연관 관계를 맺거나 JPA의 네이티브 쿼리를 사용해야 한다.

→ 시스템 상태를 변경할 때와 조회활 때 단일 도메인 모델을 사용하기 때문에 조회 시에 고민거리가 생긴다.

11.2 CQRS

상태를 변경하는 범위와 상태를 조회하는 범위가 정확하게 일치하지 않기 때문에 단일 모델로 두 종류의 기능을 구현하려면 모델이 불필요하게 복잡해진다.

→ 단일 모델을 사용할 때 발생하는 복잡도를 해결하기 위해 CQRS를 사용한다.
CQRS는 Qommand Query Responsibility Segregation의 약자로, 상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴이다.
도메인이 복잡할수록 명령 기능과 조회 기능이 다루는 데이터 범위에 차이가 난다.
또한, CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있다.
- 명령 모델은 JPA, 조회 모델은 Mybatis로 구현할 수 있다.
5장에서 소개한 @Subselect를 적용해서 조회 모델을 구현할 수도 있다.
명령 모델과 조회 모델은 서로 다른 데이터 저장소를 사용할 수도 있다.
- 명령 모델은 트랜잭션을 지원하는 RDBMS를 사용하고, 조회 모델은 조회 성능이 좋은 메모리 기반 NoSQL을 사용할 수 있다.
- 두 데이터 저장소 간 데이터 동기화는 10장에서 배운 이벤트를 활용해서 처리한다.

대규모 트래픽이 발생하는 웹 서비스는 알게 모르게 CQRS를 적용하게 된다.
조회 속도를 높이기 위해 별도 처리를 하고 있다면 명시적으로 명령 모델과 조회 모델을 구분하자.
이를 통해 조회 기능 때문에 명령 모델이 복잡해지는 것을 막을 수 있고, 명령 모델에 관계없이 조회 기능에 특화된 구현 기법을 보다 쉽게 적용할 수 있다.

CQRS 패턴을 적용할 때 얻을 수 있는 장점은 명령 모델을 구현할 때 도메인 자체에 집중할 수 있다는 점이다.
CQRS를 적용하면 조회 성능을 향상시키는 데 유리하다.
- 조회 단위로 캐시 기술을 적용할 수 있고, 조회에 특화된 쿼리를 사용할 수 있다.
- 캐시뿐만 아니라 조회 전용 저장소를 사용하면 조회 처리량을 대폭 늘릴 수도 있다.

구현해야 할 코드가 더 많아진다.
- 도메인이 단순하거나 트래픽이 많이 않은 서비스라면 조회 전용 모델을 따로 만들 때 얻을 이점이 있는지 따져봐야 한다.
더 많은 구현 기술이 필요하다.
- 명령 모델과 조회 모델은 다른 구현 기술을 사용해서 구혀하기도 하고 경우에 따라 다른 저장소를 사용하기도 한다.
- 또한, 데이터 동기화를 위해 메시징 시스템을 도입해야 할 수도 있다.