DDD - 도메인 주도 설계

앞으로 적어갈 글은 최범균님의 저서 DDD START!를 읽고 요약 - 정리한 글입니다.

제 11장 : CQRS

제 11장 CQRS

들어가기에 앞서

CORS에 익숙했는지 글을 쓰는 지금도 CQRS가 아니라 CORS로 적었다가 수정했다.

브라우저에서 발생하는 CORS에러가 아닌 CQRS에 대해서 알아보자.

단일 모델의 단점

• 주문 내역 조회 기능을 구현하기 위해서는 여러 애그리거트에서 데이터를 가져와야 한다.

• 주문 내역 조회 페이지는 로딩이 빨라야하는데 여러 도메인 모델을 가져오기 때문에 Select를 여러번 날리게 되고 결과적으로 느려지게 된다.

• 이러한 구현의 복잡도를 낮추는 간단한 방법은 상태 변경을 위한 모델과 조회를 위한 모델을 분리하는 것이다.

CQRS

• 시스템은 크게 상태를 변경하는 기능과 상태 정보를 조회하는 두 가지 기능으로 나눌 수 있다.

• 앞서 살펴본 주문 내역 조회 기능이 상태 정보를 조회하는 기능에 해당한다.

• 단일 모델로 두 종류의 기능을 구현하면 모델이 불필요하게 복잡해진다.

• 단일 모델을 사용할 때 발생하는 복잡도를 낮추기 위해 CQRS를 사용할 수 있다.

• CQRS (Command Query Responsibility Segregation)는 상태를 변경하는 명령(Command)와 조회(Query)를 위한 모델을 분리하는 패턴이다.

• CQRS는 도메인이 복잡할 수록 유리하다.

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

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

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

• 명령 모델과 조회 모델의 설계의 예

• 두 모델 모두 주문과 관련이 있지만 명령 모델은 상태를 변경하는 도메인 로직을 수행하는데 초점이, 조회 모델은 화면에 보여줄 데이터를 조회하는 데 초점이 맞춰 설계되었다.

• 또한 아예 명령을 위한 DB와 조회를 위한 DB를 구분해서 사용하는 것 또한 가능하다.

• 이를 위한 동기화는 10장에서 배운 이벤트를 사용해 전달할 수 있다.

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

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

웹과 CQRS

• 웹에서는 상태 변경 요청보다 상태 조회 요청이 더 많다.

• 조회 전용 모델을 캐싱하라

• 조회 속도를 높이고 싶다면 반드시 명령 모델과 조회 모델을 분리하자

CQRS 장단점

• CQRS 패턴을 통해 얻을 수 있는 또 다른 장점은 명령 모델을 구현할 때 도메인 자체에 집중할 수 있게 된다는 점이다.

• 복잡한 도메인은 상태 변경 로직이 복잡한데, 명령 모델과 조회 모델을 구분하면 조회 성능을 위한 코드가 명령 모델에 없으므로 도메인 로직을 구현하는 데 집중할 수 있다.

• 또 다른 장점은 조회 성능을 향상 시킬 수 있는 캐시를 조회 단위로 적용할 수 있다.

• 단점은 구현해야할 코드가 더 많다.

  • 트래픽이 많지 않은 서비스라면 명령 모델과 조회 모델을 분리하지는 말자.

• 두 번째 단점은 더 많은 구현 기술이 필요로하게 된다.

  • 다른 저장소를 사용하거나 다른 구현 기술을 사용할 수 있다.
  • 데이터 동기화를 위해 메시징 시스템을 도입해야할 수도 있다.

Reference

DDD START! - 최범균님 -

그림 및 코드 참조 : https://incheol-jung.gitbook.io/docs/study/ddd-start/1