📌 들어갑니다
현재 개발 중인 쿠폰 도메인에는 CQRS 패턴이 구현됩니다.
이런 CQRS 패턴이 무엇인지에 대해 직업 채용시 면접 질문으로 질문했다는 이야기를 점심시간에 듣게 되었습니다.
그래서 이번 포스팅을 통해 모호하게 알고 있던 개념을 정리하고 싶습니다.
📌CQRS 패턴을 사용하는 이유
주문 내역 조회 기능을 구현하는 경우 여러 집계에 액세스하여 데이터를 조회해야 합니다.
Order에서 주문 정보를, Product에서는 상품에 대한 정보를, Member에서는 회원 관련 정보를 호출해야 합니다.
그런데 룩업 화면은 그 특성상 api의 응답 속도가 빠를수록 좋지만, 이러한 상황에서는 한 번의 select 쿼리 룩업으로 필요한 데이터를 읽을 수 없어 룩업 속도에 문제가 생긴다.
수 있습니다.
이 문제가 발생하는 근본적인 이유는 시스템 상태를 변경할 때와 쿼리할 때 동일한 단일 도메인 모델을 사용하기 때문입니다.
도메인의 상태를 변경하는 것은 그다지 문제가 되지 않지만, 복수의 집계의 데이터를 취득해 정보를 출력하는 기능을 개발할 때는, 구현시에 고려할 필요가 있는 경우가 많아, 구현을 복잡하게 해 합니다.
이 구현의 복잡성을 줄이는 데 사용되는 방법은 상태 변경을 위한 모델과 쿼리를 위한 모델을 분리하는 CQRS 패턴을 사용하는 것입니다.
📌 CQRS
CQRS는 Command Query Responsibility Segregation의 약자로 상태를 변경하는 명령(Command) 모델과 상태를 제공하는 조회(Query) 모델을 분리하는 패턴입니다.
이러한 CQRS는 복잡한 도메인에 적합한 패턴입니다.
도메인이 복잡해질수록 커맨드와 룩업 기능이 다루는 데이터의 범위가 다르고, 이 두 가지 기능을 단일 모델로 처리하면 룩업 기능의 로딩 속도로 인해 모델 구현이 필요 이상으로 복잡합니다.
될 수 있습니다.
CQRS를 사용하면 각 모델에 맞는 구현 기술을 개별적으로 가져올 수 있습니다.
명령 모델은 객체 지향을 기반으로 도메인 모델의 상태를 변경하는 데 적합한 JPA를 사용하여 구현되며 룩업 모델은 DB 테이블에서 SQL로 데이터를 쿼리 할 때 좋은 MyBatis를 사용하여 구현됩니다.
수 있습니다.
현재 개발 중인 도메인은 위의 패키지 구조 이미지와 같이 쿼리 service 와 명령 service 가 구별되고 있습니다.
그러나 이것은 엄밀히 말하면 쿼리 서비스와 명령과 관련된 응용 프로그램 서비스를 구별 할 수 있으며 모델을 구별하여 사용하는 것은 아닙니다.
물론 queryservice에는 쿼리 성능을 높이기 위한 redis cache 등이 적용되어 쿼리 성능을 높이기 위한 기법이 사용되어 CQRS를 필요로 하는 효과를 보이고 있지만 모델은 구별되지 않습니다.
위의 그림은 DDD-START 책에 표시된 CQRS 구현 방법의 예입니다.
이 그림을 보면 조회 모델에는 응용 프로그램 서비스가 없습니다.
단순히 데이터를 읽고 검색하는 기능은 애플리케이션 로직이 복잡하지 않기 때문에 컨트롤러에서 DAO를 즉시 실행해도 괜찮습니다.
물론 데이터를 표현 영역에 전달하는 과정에서 몇 가지 로직이 필요한 경우 애플리케이션 서비스에 로직을 구현할 수 있습니다.
이와 같이, 커멘드 모델과 룩업 모델이 다른 데이터 스토어를 사용하는 경우, 데이터 동기의 시점에 의해 구현 방법이 다른 경우가 있습니다.
명령 모델에서 데이터가 변경되자마자 변경 기록이 조회 모델에 반영되어야 하는 경우 동기화 이벤트와 글로벌 트랜잭션을 사용하여 실시간으로 동기화할 수 있습니다.
그러나 동기 이벤트와 글로벌 트랜잭션은 전반적인 성능(응답 속도 및 처리량) 저하의 주요 원인이므로 사용에 주의해야 합니다.
📌 CQRS의 장점과 단점
CQRS 패턴을 적용하는 장점은
- 명령 모델을 구현할 때 도메인 자체에 집중할 수 있습니다.
- 규모가 큰 도메인은 주로 상태 변경 로직이 복잡하고 룩업 성능을 위한 코드가 명령 모델에 없기 때문에 도메인 로직 구현에 집중할 수 있습니다.
- 규모가 큰 도메인은 주로 상태 변경 로직이 복잡하고 룩업 성능을 위한 코드가 명령 모델에 없기 때문에 도메인 로직 구현에 집중할 수 있습니다.
- 조회 성능을 향상시키는 데 유리합니다.
- 조회 단위로 캐시 기술을 적용할 수 있습니다.
- 조회 전용 저장소를 사용하면 조회 처리량을 크게 늘릴 수 있습니다.
- 조회 단위로 캐시 기술을 적용할 수 있습니다.
CQRS 패턴을 적용할 때의 단점은
- 구현해야 하는 코드는 단일 모델에 비해 증가합니다.
- 단일 모델을 사용할 때 발생하는 복잡성 대문에서 발생하는 구현 비용 및
- 조회 전용 모델을 작성할 때 발생하는 구현 비용을 고려해야 합니다.
- 더 많은 구현 기술이 필요합니다.
- 명령 모델과 조회 모델을 다른 기술을 사용하여 구현하거나 경우에 따라 다른 리포지토리를 사용합니다.
- 명령 모델과 조회 모델을 다른 기술을 사용하여 구현하거나 경우에 따라 다른 리포지토리를 사용합니다.
이러한 장점과 단점을 모두 고려하여 현재 도메인에 가장 적합한 구조를 채택해야 합니다.
도메인이 복잡하지 않고 CQRS 패턴을 도입하면 두 모델을 모두 유지하는 비용이 높아지고 이점이 없을 수 있습니다.
참고: DDD-START!
도메인 주도 설계 구현 및 핵심 개념 습득