도메인주도개발 시작하기 11장 CQRS

CQRS란 Command and Query Responsibility Segregation 의 약자로, 데이터 저장소로부터의 읽기와 업데이트 작업을 분리하는 패턴을 말한다

 

여러 애그리거트의 데이터가 필요하면 다양한 방안의 구현방법을 고민해야한다.

식별자를 이용해서 애그리거트를 참조하는 방식을 사용하여 가져와한다.

 

상태 변경 기능은 주로 한 애그리거트의 상태를 변경한다.

반면, 조회 기능은 두 개 이상의 애그리거트가 필요할 때가 많다.

 

상태를 변경하는 범위와 조회하는 범위가 일치하지 않기 때문에 단일 모델로 두 종류의 기능을 구현하면 모델이 불필요하게 복잡해진다.

 

위 복잡도를 해결하기 위해 사용하는 방법이 CQRS이다. 

CQRS : 명령(Command)을 위한 모델과 조회(Query)를 위한 모델을 분리하는 패턴

CQRS는 복잡한 도메인에 적합하다.

CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있다.

예를 들어 명령 모델은 객체지향에 기반하여 도메인 모델을 구현하기에 JPA를 사용하고 ,

조회 모델은 SQL로 데이터 조회할 때 좋은 마이바티스를 사용해서 구현하면 된다.

 

조회 모델은 조회 성능에 좋은 NoSql를 사용할 수 있다.

두 데이터 간 동기화는 이벤트를 활용하여 처리한다.

명령 모델에서 데이터가 바뀌자마자 조회 모델에 반영해야 한다면, 동기 이벤트와 글로벌 트랜젝션을 사용하여 실시간으로 동기화 할 수 있다.

특정 시간 안에만 동기화 해도 된다면, 비동기로 데이터를 전송하면 된다.

 

일반적으로 웹서비스는 상태 변경 요청보다, 조회하는 요청이 많다.

메모리에 캐싱하는 데이터는 DB에 보관된 데이터를 그대로 저장하기 보다는 변환한 데이터를 캐싱할 때 성능에 더 유리하다.

조회 속도를 높이기 위해서 병도 처리를 하고 있다면 명시적으로 CQRS 패턴을 적용하는게 좋다.

 

CQRS 패턴을 통해 명령 모델을 구현하면 도메인 자체에 집중할 수 있다는 장점이 있다. 

또한, 캐시적용이나 조회쿼리 튜닝 등을 통해 조회 성능을 향상시킬 수 있다.

물론, 구현할 코드가 많아진다는 문제점이 있고, 메시징 시스템 같은 더 많은 구현 기술이 필요할 수도 있다는 단점이 있다.

장단점을 고려했을 때, 도메인이 복잡하지 않을 때 CQRS를 도입하면 유지비용만 높아지고 이점이 없는 문제가 있다!

 

개인적인생각: 도메인이 복잡했을 경우 CQRS를 사용하여 분리를 하는것이 유지비용측면에서 좋아보인다. 

만약 쓸일이 있더라도 write하는 db가 많아질 경우 read하는 데이터들의 동기화가 제대로 되지않아 

데이터의 정합성 측면에서 오류가 생길 수 있다. 따라서

write는 하나만

read는 여러개 해서 최대한 동기화시킨다. 그래서 잘 안된다면 aws region을 제일 가깝고 가속화를 시켜

최대한 동기화를 맞추는 방식으로해야할 것 같다.