CQRS 패턴의 장단점을 고려해 적용할지 결정해야 한다.
시스템이 제공하는 기능은 크게 상태를 변경하는 기능과 상태 정보를 조회하는 기능으로 나눌 수 있다.
도메인 모델 관점에서 상태 변경 기능은 주로 한 애그리거트의 상태를 변경한다.
반면 조회 기능에 필요한 데이터를 표시하려면 두 개 이상의 애그리거트가 필요할 때가 많다.
두 기능의 범위가 정확하게 일치하지 않기 때문에 단일 모델로 두 종류의 기능을 구현하면 모델이 복잡해진다.
단일 모델을 사용할 때 발생하는 복잡도를 해결하기 위해 사용하는 방법이 CQRS다.
CQRS는 Command Query Responsibility Segregation의 약자로 상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴이다.
도메인이 복잡할수록 명령 기능과 조회 기능이 다루는 데이터 범위에 차이가 나 CQRS가 적합하다.
CQRS를 사용하면 다음과 같이 각 모델에 맞는 구현 기술을 선택할 수 있다.
상태 변경을 위한 명령 모델은 객체를 기반으로 한 도메인 모델을 이용해 구현한다.
조회 모델은 조회 기능에 필요한 정보를 담고 있는 데이터 타입을 이용한다.
명령 모델은 상태를 변경하는 도메인 로직을 수행하는 데 초점을 맞춰 설계했고, 조회 모델은 화면에 보여줄 데이터를 조회하는 데 초점을 맞춰 설계했다.
명령 모델과 조회 모델이 서로 다른 데이터 저장소를 사용할 수도 있다.
명령 모델은 트랜잭션을 지원하는 RDBMS를 사용하고, 조회 모델은 조회 성능이 좋은 메모리 기반 NoSQL을 사용할 수 있다.
일반적인 웹 서비스는 상태를 변경하는 요청보다 상태를 조회하는 요청이 많다.
따라서 개발팀은 조회 성능을 높이기 위해 기본적으로 쿼리를 최적화하고 메모리에 조회 데이터를 캐싱 해서 응답 속도를 높이기도 한다.
혹은 조회 전용 저장소를 따로 사용하기도 한다.
이런 다양한 기법들은 결과적으로 CQRS를 적용하는 것과 같은 효과를 만든다.
명령 모델을 구현할 때 도메인 자체에 집중할 수 있다는 장점이 있다.
명령 모델에서 조회 관련 로직이 사라져 복잡도가 낮아지고 도메인 로직을 구현하는 데 집중할 수 있다.
또 조회 단위로 캐시 기술을 적용할 수 있고 조회에 특화된 쿼리를 마음대로 사용할 수 있어 조회 성능을 향상시키는 데 유리하다.
조회 저장소를 사용하면 조회 처리량을 대폭 늘릴 수 있다.
하지만 구현해야 할 코드가 더 많고 더 많은 구현 기술이 필요하다는 단점이 있다.
장단점을 고려해 CQRS 패턴을 도입할지 여부를 결정해야 한다.
CQRS는 도메인 로직이 복잡하고 명령 모델을 조회 모델로 사용했을 때 구현하는 비용이 조회 모델을 따로 구현하는 비용보다 비쌀 때 적용해야 한다.
도메인이 단순한 서비스에서 CQRS를 도입하는 것은 오히려 구현 비용을 높이는 행위로 볼 수 있다.
물론 조회 모델과 명령 모델을 분리함으로써 얻는 이점이 크기 때문에 장점이 더욱 크다고 생각한다.
자신의 상황에 맞게 CQRS를 어떻게 도입할지, 도입하지 않을지 결정해야 한다.