[DDD START] 11장 CQRS

이 포스트는 📔 도메인 주도 개발 시작하기 책을 읽고 공부한 내용을 정리한 포스트입니다.

11장. CQRS

11.1 단일 모델의 단점

단일 모델을 사용할때의 단점은 시스템의 상태를 변경할 때와 조회 할 때 모두 하나의 모델을 사용하기에 상태 변경에 치중된 모델은 조회 과정 및 성능이 좋지 않고, 역으로 조회에 치중된 모델은 상태 변경 과정 및 성능이 좋지 않다는 점이다.

이러한 구현 복잡도를 낮추기 위해서는 어떻게 해야할까? 바로 상태 변경을 위한 모델과 조회를 위한 모델을 분리(Command and Query Responsibility Segregation)하는 것이다.

11.2 CQRS

시스템이 사용자에게 제공하는 기능은 상태 변경과 조회로 나눌 수 있다. 상태를 변경하는 범위와 상태를 조회하는 범위가 정확하게 일치하기는 매우 어렵기에 단일 모델을 활용해서 두 범위를 한번에 처리하기는 너무 복잡하다. 이 경우 복잡도를 해결하기 위해 사용하는 방법이 바로 CQRS이다.

CQRS는 상태를 변경하는 명령(command)와 상태를 조회(query)하는 모델을 분리하는 패턴을 이야기한다.

CQRS 패턴을 적용함으로써 명령 모델을 구현할 때 도메인 자체에 집중할 수 있다는 점과 조회 성능을 향상시키기 유리하다는 점을 장점으로 갖을 수 있다.
하지만 구현 코드가 많아진다는 단점과 적용해야 할 구현 기술이 더 많이 필요하다는 점도 단점으로 나타난다.

이러한 두 장단점을 고려해서 CQRS를 적용할지 여부를 결정하는 것이 중요하다.