11장 CQRS

11.1 단일 모델의 단점

조회 화면 특성상 조회 속도가 빠를수록 좋은데 여러 애그리거트의 데이터가 필요하면 구현 방법을 고민해야함

이런 고민이 발생하는 이유는 시스템 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하기 때문이다.

객체 지향으로 도메인 모델을 구현할 때 주로 사용하는 ORM 기법은 도메인 상태 변경 기능을 구현하는 데는 적합하지만

주문 상세 조회 화면처럼 여러 애그리거트에서 데이터를 가져와 출력하는 기능을 구현하기에는 쉽지 않다.

→ 이를 해결하는 방법은 상태 변경을 위한 모델과 조회를 위한 모델을 분리하는 것이다.

 

11.2 CQRS

• 시스템이 제공하는 기술은 크게 상태를 변경하는 기능과 상태 정보를 조회하는 기능 , 두 가지이다.
• 도메인 모델 관점에서 상태 변경 기능은 주로 한 애그리거트의 상태를 변경한다.
• 반면 조회 기능에 필요한 데이터를 표시하려면 두 개 이상의 애그리거트가 필요할 때가 많다
• 상태를 변경하는 범위와 상태를 조회하는 범위가 정확하게 일치하지 않기 때문에 단일 모델로 두 종류의 기능을 구현하면 모델이 불필요하게 복잡해진다.

이럴 때 사용하는 방법이 CQRS이다.

 

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

• CQRS는 복잡한 도메인에 적합하다.
• CQRS를 적용하면 통계를 위한 조회 모델을 별도로 만들기 때문에 조회 기능 때문에 도메인 모델이 복잡해지는 것을 막을 수 있다.
• CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있다.
  • 명령 모델은 객체 지향에 기반해서 도메인 모델을 구현하기에 적합한 JPA를 사용해서 구현하고,
  • 조회 모델은 DB 테이블에서 SQL로 데이터를 조회할 때 좋은 마이바티스를 사용해서 구현하면 된다.
• 단순히 데이터를 읽어와 조회하는 기능을 응용 로직이 복잡하지 않기 때문에 컨트롤러에서 바로 DAO를 실행해도 무방하다.
• 명령 모델과 조회 모델이 같은 구현기술을 사용할 수 있다.
  • JPQL을 이용한 동적 인스턴스 생성 , 하이버네이트
• 명령 모델과 조회 모델이 서로 다른 데이터 저장소를 사용할 수 있다.
  • 명령 모델은 트랜잭션을 지원하는 RDBMS를 사용하고 조회 모델은 조회 성능이 좋은 메모리 기반 NoSQL을 사용할 수 있다.
  • 두 데이터 저장소 간 데이터 동기화는 이벤트를 활용해서 처리한다.
  • 두 모델이 다른 데이터 저장소를 사용하면 데이터 동기화 시점에 따라 구현 방식이 달라질 수 있다.
    • 동기 이벤트와 글로벌 트랜잭션을 사용해서 실시간 동기화 하거나
    • 특정 시간 안에만 동기화해도 된다면 비동기로 데이터를 전송해도 된다.

 

11.2.1 웹과 CQRS

• 일반적인 웹 서비스는 상태를 변경하는 요청보다 상태를 조회하는 요청이 많다
• 조회 성능을 높이기 위해 다양한 기법을 사용하는 것은 결과적으로 CQRS를 적용하는 것과 같은 효과를 만든다.
  • 메모리에 캐싱 하는 데이터는 DB에 보관된 데이터를 그대로 저장하기 보다는 화면에 맞는 모양으로 변환한 데이터를 캐싱 할 때 성능이 더 유리하다

 

11.2.2 CQRS의 장단점

 

장점

• 명령 모델을 구현할 때 도메인 자체에 집중할 수 있다.
• 명령 모델에서 조회 관련 로직이 사라져 복잡도가 낮아진다.
• 조회 성능을 향상시키는데 유리하다.

단점

• 구현해야할 코드가 더 많다.
• 더 많은 구현 기술이 필요하다

이런 장단점을 고려해서 CQRS 패턴을 도입할지 여부를 정해야한다.