CQRS 패턴

단일 모델의 단점

• 주문 내역 조회 기능을 구현하기 위해서는 여러 애그리거트에서 데이터를 가져와야 한다.
• 주문 내역 조회 페이지는 로딩이 빨라야하는데 여러 도메인 모델을 가져오기 때문에 Select를 여러번 날리게 되고 결과적으로 느려지게 된다.
• 이러한 구현의 복잡도를 낮추는 간단한 방법은 상태 변경을 위한 모델과 조회를 위한 모델을 분리하는 것이다.

상태를 변경하는 범위와 상태를 조회하는 범위가 정확하게 일치하지 않기 때문에 단일 모델로 두 종류의 기능을 구현하면 모델이 불필요하게 복잡해진다. 단일 모델을 사용할 때 발생하는 복잡도를 해결하기 위해 사용하는 방법이 있는데, 그것이 CQRS이다.

 

CQRS는 Command Query Responsibility Segregation의 약자로 상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴이다.

CQRS는 복잡한 도메인에 적합하다. 도메인이 복잡할수록 명령 기과 조회 기능이 다루는 데이터 범위에 차이가 발생하는데, 이 두 기능을 단일 모델로 처리하게 되면 조회 기능의 로딩 속도를 위해 모델 구현이 필요 이상으로 복잡해지는 문제가 발생한다.

예를 들어, 온라인 쇼핑몰에서 다양한 차원에서 주문/판매 통계를 조회해야한다고 가정하자.

• JPA 기반의 단일 도메인 모델을 사용하면 통계 값을 빠르게 조회하기 위해 JPA와 관련된 다양한 성능 관련 기능을 모델에 적용해야한다.
• 이런 도메인에 CQRS를 적용하면 조회 모델을 별도로 만들기 때문에 조회 때문에 도메인 모델이 복잡해지는 것을 막을 수 있다.

예를 들어, 명령 모델은 객체 지향에 기반한 도메인 모델을 구현하기에 적당한 JPA를 사용하고 조회 모델은 DB에서 SQL로 데이터를 조회할 때 좋은 MyBatis를 사용해서 구현할 수 있다.

위를 보면, 조회 모델에서는 응용 서비스가 존재하지 않는다. 단순히 데이터를 읽어아 조회하는 기능은 응용 로직이 복잡하지 않기 때문에 컨트롤러에서 바로 DAO를 실행해도 무방하다.

• 또한 아예 명령을 위한 DB와 조회를 위한 DB를 구분해서 사용하는 것 또한 가능하다.
• 이를 위한 동기화는 10장에서 배운 이벤트를 사용해 전달할 수 있다.

CQRS 패턴을 적용하기 위한 별도의 기술이 존재하는 것은 아니다

명령 모델을 JPA로 구현하고 조회 모델은 직접 SQL을 사용해 구현할 수도 있다

웹과 CQRS

• 웹에서는 상태 변경 요청보다 상태 조회 요청이 더 많다.
• 조회 전용 모델을 캐싱하라
• 조회 속도를 높이고 싶다면 반드시 명령 모델과 조회 모델을 분리하자

CQRS 장단점

• CQRS 패턴을 통해 얻을 수 있는 또 다른 장점은 명령 모델을 구현할 때 도메인 자체에 집중할 수 있게 된다는 점이다.
• 복잡한 도메인은 상태 변경 로직이 복잡한데, 명령 모델과 조회 모델을 구분하면 조회 성능을 위한 코드가 명령 모델에 없으므로 도메인 로직을 구현하는 데 집중할 수 있다.
• 또 다른 장점은 조회 성능을 향상 시킬 수 있는 캐시를 조회 단위로 적용할 수 있다.
• 단점 은 구현해야 할 코드가 더 많다
• 트래픽이 많지 않은 서비스라면 명령 모델과 조회 모델을 분리하지는 말자.
• 두 번째 단점은 더 많은 구현 기술이 필요로 하게 된다.
  • 다른 저장소를 사용하거나 다른 구현 기술을 사용할 수 있다.
  • 데이터 동기화를 위해 메시징 시스템을 도입해야할 수도 있다.