[도메인 주도 개발 시작하기] 11. CQRS

 

시스템이 제공하는 기능은 크게 두 가지로 나눌 수 있다.

 

1. 상태를 변경하는 기능
2. 상태 정보를 조회하는 기능

 

상태를 변경하는 범위와 상태를 조회하는 범위가 정확하게 일치하지 않기 때문에 단일 모델로 두 종류의 기능을 구현하면 모델이 불필요하게 복잡해진다. 단일 모델을 사용할 떄 발생하는 복잡도를 해결하기 위해 CQRS를 사용한다.

 

CQRS는 Command Query Responsibility Segregation의 약자로, 상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴이다.

 

 

CQRS는 복잡한 도메인에 적합하다. 도메인이 복잡해질수록 명령 기능과 조회 기능이 다루는 데이터 범위에 차이가 난다. CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있다. 예를 들어 명령 모델은 객체 지향에 기반해서 도메인 모델을 구현하기에 적당한 JPA를 사용해서 구현하고, 조회 모델은 DB 테이블에서 SQL로 데이터를 조회할 때 좋은 마이바티스를 사용해서 구현하면 된다. 명령 모델은 상태를 변경하는 도메인 로직을 수행하는 데 초점을 맞춰 설계하고, 조회 모델은 화면에 보여줄 데이터를 조회하는 데 초점을 맞춰 설계할 수 있다.

 

또한 명령 모델과 조회 모델이 서로 다른 데이터 저장소를 사용할 수도 있다. 명령 모델은 트랜잭션을 지원하는 RDBMS를 사용하고, 조회 모델은 조회 성능이 좋은 메모리 기반 NoSQL을 사용할 수 있다. 두 데이터 저장소 간 데이터 동기화는 이벤트를 활용해서 처리할 수 있는데, 명령 모델에서 상태를 변경하면 이에 해당하는 이벤트가 발생하고, 그 이벤트를 조회 모델에 전달해서 변경 내역을 반영하면 된다.

 

CQRS의 장단점

 

명령 모델을 구현할 때 도메인 자체에 집중할 수 있는 장점이 있다. 복잡한 도메인은 주로 상태 변경 로직이 복잡한데 명령 모델과 조회 모델을 구분하면 조회 성능을 위한 코드가 명령 모델에 없으므로 도메인 로직을 구현하는 데 집중할 수 있다. 또한 명령 모델에서 조회 관련 로직이 사라져 복잡도가 낮아진다.

 

또한 조회 성능을 향상시키는 데 유리하다. 조회 단위로 캐시 기술을 적용할 수 있고, 조회에 특화된 쿼리를 마음대로 사용할 수도 있다. 캐시뿐만 아니라 조회 전용 저장소를 사용하면 조회 처리량을 대폭 늘릴 수도 있다. 조회 전용 모델을 사용하기 때문에 조회 성능을 높이기 위한 코드가 명령 모델에 영향을 주지 않는다.

 

반면에, 구현해야 할 코드가 더 많아진다. 단일 모델을 사용할 때 발생하는 복잡함 때문에 발생하는 구현 비용과 조회 전용 모델을 만들 때 발생하는 구현 비용을 따져봐야 한다. 또한 더 많은 구현 기술이 필요하다. 명령 모델과 조회 모델을 다른 구현 기술을 사용해서 구현하기도 하고 경우에 따라 다른 저장소를 사용하기도 한다. 또한 데이터 동기화를 위해 메시징 시스템을 도입해야 할 수도 있다.

 

CQRS 패턴의 장단점을 고려해서 패턴을 도입할지 여부를 결정해야 한다.

 

 

출처 : 최범균, 『도메인 주도 개발 시작하기 DDD 핵심 개념 정리부터 구현까지』, 한빛미디어(2022), p344-p352