11. CQRS
#
단일 모델의 단점- 주문 내역 조회 기능을 구현하려면 여러 애그리거트에서 데이터를 가져와야합니다.
- ex. Order, Product, Member
- 조회 화면의 특성상 조회 속도가 빠를수록 좋은데 여러 애그리거트에서 데이터를 가져와야할 경우 구현 방법을 고민해야합니다.
- 이러한 이유가 발생하는 이유는 시스템의 상태를 변경할 때와 조회할때 단일 도메인 모델을 사용하기 때문입니다.
- 구현 복잡도를 낮추는 간단한 방법은 상태 변경을 위한 모델과 조회를 위한 모델을 분리하는 것입니다.
#
CQRS- 시스템이 제공하는 기능은 크게 상태를 변경하는 기능과 상태 정보를 조회하는 기능으로 나누어 볼 수 있습니다.
- 도메인 모델 관점에서 상태 변경 기능은 주로 한 애그리거트의 상태를 변경합니다.
- CQRS는 Command Query Responsibility Segregation의 약자로, 상태를 변경하는 명령(Command)을 위한 모델과 상태를 제공하는 조회(Query)을 위한 모델을 분리하는 패턴입니다.
- CQRS는 복잡한 도메인에 적합합니다.
- 복잡할 수록 명령 기능과 조회 기능이 다루는 데이터 범위에 차이가 발생하는데 이를 단일로 처리하면 복잡해집니다.
- CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있습니다.
- 명령 모델과 조회 모델이 서로 다른 데이터 저장소를 사용할 경우 데이터 동기화 시점에 따라 구현 방식이 달라질 수 있습니다.
- 서로 다른 저장소의 데이터를 특정 시간 안에만 동기화하면 된다면 비동기로 데잍러르 전송해도 됩니다.
#
웹과 CQRS- 일반적인 웹 서비스는 상태를 변경하는 요청보다 상태를 조회하는 요청이 많습니다.
- 조회 성능을 높이기 위해 다양한 기법을 사용하는 것은 결과적으로 CQRS를 적용하는 것과 같은 효과를 만듭니다.
- 대규모 트래픽이 발생하는 웹 서비스는 알게 모르게 CQRS를 적용하게 됩니다.
#
CQRS 장단점- CQRS의 장점
- 명령 모델을 구현할 때 도메인 자체에 집중할 수 있습니다.
- 조회 성능을 향상시키는 데 유리합니다.
- CQRS의 단점
- 구현해야 할 코드가 더 많습니다.
- 더 많은 구현 기술이 필요합니다.
- 위의 장단점을 고려하여 CQRS 패턴을 도입할지 여부를 결정해야합니다. (복잡성에 따라)