[DDD] 도메인 주도 개발 시작하기

Chapter 11 CQRS

11.1 단일 모델의 단점

주문 내역 조회 기능을 구현하려면 여러 애그리거트에서 데이터를 가져와야 됨

조회 기능을 구현할 때 식별자를 이용해서 애그리거트를 참조하면 즉시 로딩과 같은 JPA의 쿼리 관련 최적화 기능을 사용할 수 없음. 직접 참조하더라도 조회 화면 특성에 따라 같은 연관도 즉시 로딩이나 지연 로딩으로 처리해야 되므로 고민해야 됨.

이러한 문제는 시스템 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하기 때문

이런 상황에서 구현 복잡도를 낮추려면 상태 변경을 위한 모델과 조회를 위한 모델을 분리하면 됨

11.2 CQRS

시스템이 제공하는 기능 : 상태를 변경하는 기능, 사용자 입장에서 상태 정보를 조회하는 기능

도메인 모델 관점에서 상태 변경 기능은 주로 한 애그리거트의 상태를 변경

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

CQRS(Command Query Responsibility Segregation) : 단일 모델을 사용할 때의 복잡도 해결을 위해 사용. 상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴

도메인이 복잡할수록 명령 기능과 조회 기능이 다루는 데이터 범위에 차이가 나기 때문에 CQRS는 복잡한 도메인에 적합

CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있음 ex. 응용 서비스 여부, 모델 설계, 데이터 저장소 종류

다른 저장소를 사용할 경우에는 이벤트를 이용해서 두 데이터 저장소 간 데이터를 동기화함

특정 시간 안에만 동기화해도 되면 비동기로 데이터를 전송해도 됨

11.2.1 웹과 CQRS

일반적인 웹 서비스는 상태 변경 요청보다 상태 조회 요청이 월등히 많음. 이런 상황에서 조회 성능을 높이기 위해 사용하는 기법은 결과적으로 CQRS를 적용한 것과 같은 효과를 냄

11.2.2 CQRS 장단점

장점

- 명령 모델을 구현할 때 도메인 자체에 집중할 수 있음

- 조회 성능을 위한 코드가 명령 모델과 분리됨

- 조회 성능을 향상시키는 데 유리함

- 조회 단위로 캐시 기술을 적용할 수 있음

- 조회에 특화된 쿼리를 마음대로 사용할 수 있음

단점

- 구현해야 할 코드가 더 많음 => 도메인이 단순하거나 트래픽이 많지 않은 서비스는 CQRS 사용을 고민해봐야 됨

- 더 많은 구현 기술이 필요함

Archive