Notice
Recent Posts
Recent Comments
Link
«   2024/07   »
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
Tags
more
Archives
Today
Total
관리 메뉴

공hannah부

[도메인 주도 개발 시작하기] -11장 CQRS 본문

공부/백엔드

[도메인 주도 개발 시작하기] -11장 CQRS

Hannah0226 2024. 5. 2. 14:42

11.1 단일 모델의 단점

주문 내역 조회 기능 구현 시 여러 애그리거트에서 데이터를 가져와야 함

  • Order에서 주문정보 가져오기
  • Product에서 상푸무 이름 가져오기
  • Member에서 회원이름 가져오기 등

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

  1. 식별자를 이용해서 애그리커드를 참조하는 방식: 즉시로딩 방식과 같은 JPA의 쿼리 관련 최적화 기능 사용 불가능
  2. 애그리거트 간 연관을 식별자가 아니라 직접 참조하는 방식: 같은 연관도 즉시 로딩이나 지연로딩으로 처리해야 함

이러한 고민이 발생하는 이유

  • 시스템 상태를 변경할 때와 조회할 때 단일 도메인 모델은 사용하기 때문
     상태 변경을 위한 모델과 조회를 위한 모델을 분리해 구현 복잡도를 낮출 수 있음

 

11.2 CQRS

시스템이 제공하는 기능

  • 상태 변경 기능
    ex) 새로운 주문 생성, 배송지 정보 변경, 회원 암호 변경 등
  • 상태 정보 조회 기능
    ex) 주문 상세 내역 보기, 게시글 목록 보기, 회원 정보 보기, 판매 통계 보기 등

도메인 모델 관점

  •  상태 변경 기능
    :
    한 애그리거트의 상태를 변경함
    ex) 주문 취소 기능과 배송지 정보 변경 기능은 한 개의 Order 애그리거트를 변경
  • 조회 기능
    : 필요한 데이터를 표시하려면 두 개 이상의 애그리거트가 필요할 때가 많음
    ex) 주문 상세 조회 기능

→ 상태 변경 기능과 조회 기능은 범위가 정확하게 일치하지 않기 때문에 단일 모델로 구현하면 모델이 복잡해짐

CQRS를 사용해 해결

 

CQRS

  • Command Query Responsibility Segregation
  • 상태를 변경하는 명령(Command)을 위한 모델과 상태를 제공하는 조회(Query)를 위한 모델을 분리하는 패턴
  • 복잡한 도메인 모델에 적합
    • 도메인이 복잡할수록 명령 기능과 조회기능이 다루는 데이터 범위에 차이가 남
    • ex) 온라인 쇼핑몰에서 다양한 차원의 주문/판매 통계를 조회하는 경우 CQRS를 적용하면 통계를 위한 조회 모델을 별도록 만들기 때문에 조회 기능으로인해 도메인 모델이 복잡해지는 것을 막을 수 있음
  • 각 모델에 맞는 구현 기술 선택 가능
    • ex1) 모델 명령 모델은 객체 지향에 기반해서 도메인 모델을 구현하기에 적당한 JPA 사용, 조회 모델은 DB 테이블에서 SQL로 데이터를 조회할 때 좋은 마이바티스 사용
    • ex2) 명령 모델은 트랜잭션을 지원하는 RDBMS를 사용하고, 조회 모델은 조회 성능이 좋은 NoSQL을 사용하는 등 명령 모델과 조회 모델이 서로 다른 데이터 저장소를 사용할 수도 있음

11.2.1 웹과 CQRS

일반적인 웹서비스

  • 일반적인 웹서비스는 상태를 변경하는 요청보다 상태를 조회하는 요청이 많음
    → 포털이나 대형 온라인 쇼핑몰과 같이 조회 기능 요청 비율이 월등히 높은 서비스는 조회 성능을 높이기 위해 다양한 기법 사용
  • 다양한 기법
    • 쿼리를 최적화해서 쿼리 실행 속도 자체를 높이기
    • 메모리에 조회 데이터를 캐싱해서 응답 속도 높이기
    • 조회 전용 저장소를 따로 사용하기 등
      → 이렇게 조회 성능을 높이기 위해 다양한 기법을 사용하는 것은 결과적으로 CQRS를 적용하는 것과 같은 효과를 만듬

11.2.2 CQRS의 장단점

장점

  • 명령 모델을 구현할 때 도메인 자체에 집중할 수 있음
    : 명령 모델과 조회 모델을 구분하면 조회 성능을 위한 코드가 명령 모델에 없으므로 도메인 로직을 구현하는데 집중 할 수 있음
  • 조회 성능을 향상시키는데 유리
    : 조회 단위로 캐시 기술 적용 가능, 조회에 특화된 쿼리 마음대로 사용 가능, 조회 전용 저장소를 사용하면 조회 처리량 늘릴 수 있음

단점

  • 구현해야 할 코드가 더 많음
    : 단일 모델을 사용할 때 발생하는 복잡함 때문에 발생하는 구현 비용과 조회 전용 모델을 만들 때 발생하는 구현 비용을 따져봐야 함
  • 더 많은 구현 기술이 필요
    : 명령 모델과 조회 모델을 다른 구현 기술을 사용해서 구현하거나 경우에 따라 다른 저장소를 사용하기도 함. 또한 데이터 동기화를 위해 메시징 시스템을 도입해야 할 수도 있음

11장을 마치며...

11장에서는 CQRS에 대한 내용을 정리해 보았다. 이를 공부하며 도메인이 복잡하고 트래픽이 높은 서비스를 구현할 때 CQRS를 적용한다면 효율적인 효과를 얻을 수 있음을 알게되었다. 다만 단일 모델을 사용할 때 발생하는 복잡함 때문에 발생하는 구현 비용과 조회 전용 모델을 만들 때 발생하는 구현 비용을 따져보며 이를 적용할지 안할지 잘 고려해야 한다는 것 또한 알게되었다. 앞으로 프로젝트를 진행할 때 이러한 것들을 잘 따져보며 개발해야겠다!