CQRS Pattern
- 단순한 시스템은 상태 변경, 상태 조회가 동일한 모습 갖지만, 조금만 복잡해져도 상태 변경에 사용하는 데이터와 상태 조회 시 사용하는 데이터에 차이가 생긴다.
- 예를 들어 주문.
- 주문 생성 시 주문 ID, 회원 ID, 배송지 주소, 상품 ID 같은 데이터 사용한다.
- 반면 주문 정보 조회시에는 이들 정보 외에도 회원 이름, 상품명 같은 데이터 추가로 사용한다.
- 명령과 조회에서 사용하는 데이터가 서로 다른 것.
- 이렇게 명령과 조회가 서로 다른 데이터를 사용함에도 하나의 모델로 명령과 조회를 모두 구현하면 모델이 복잡해지고 유지보수가 어려워진다.
- 도메인이 복잡해질 경우 CQRS 패턴을 사용해서 이런 복잡도 문제 해결이 가능하다.
- CQRS는 Command Query Responsibility Segregation의 약자.
- 명령을 위한 모델과 조회를 위한 모델을 분리하는 패턴.
- 여기서 명령은 시스템의 상태를 변경하는 것.
- 조회는 상태를 조회하는 것.
- CQRS는 명령 모델과 조회 모델 구분하므로 각 기능에 맞게 모델 구현가능한 이점 존재.
- 단일 모델 사용할 경우 조회 기능 때문에 명령 기능이 영향 받거나, 반대로 명령 기능때문에 조회 기능이 영향 받을 수 있다.
- CQRS는 이 두 모델 분리해 이련 문제 최소화함.
- 또한, 조회 모델 따로 존재하니 조회 성능 향상이 쉽다.
- 조회 모델에 캐시 적용하거나, 조회 전용 DB 확장하는 방식.
- 단점. 각 기능마다 모델 만들어야되서 코드 늘어남.
- 단순한 모델에 CQRS 도입시 작업량만 늘고 얻는 이점은 적을 수 있다.
- 다른 단점은 구현 기술이 늘어날 수있는것.
- 명령 모델과 조회 모델을 서로 다른 기술로 구현할 때 많은데, 특히 높은 트래픽을 처리하기위해 조회 모델을 별도 조회 전용 DB에 구축하는 경우 있다.
- 이경우 서로다른 DB 간 데이터 동기화 위해 추가적 메시징 수단을 도입해야한다.