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

SoyeonCha 2024. 4. 29. 20:24

11.1 단일 모델의 단점

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

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

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

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

11.2 CQRS

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

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

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

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

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

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

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

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

11.2.1 웹과 CQRS

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

11.2.2 CQRS 장단점

∘ 장점

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

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

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

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

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

∘ 단점

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

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