작성
·
237
0
강사님 안녕하세요.
강의를 다 듣고 배운 내용을 개인 프로젝트를 통해 구현하는중입니다.
제가 CQRS에 대한 오해가 있는 것 같아 질문 드립니다.
CQRS는 도메인을 도메인 답게 유지하기 위해 비지니스 로직에 query가 침투하는 것을 막는다.
즉 command, query를 역할에 따라 분리한다.
라고 이해했는데요.
그렇다면, command만 수행하는 서버, query만 수행하는 서버로 분리하는게 맞을까요?
로직상 command를 통해 데이터를 저장 혹은 업데이트하려고 하면, db에서 해당 데이터에 대한 조회가 필수적이라고 생각하는데 이러한 조회도 command의 한 종류라고 생각하면 되는걸까요?
답변 1
2
네 CQRS의 개념과 장점에 대해 정리해 보면 다음과 같습니다.
관심 사항 분리: CQRS는 데이터를 수정하는 작업(명령)과 데이터를 읽는 작업(쿼리) 간의 명확한 분리를 촉진합니다. 이러한 분리는 각 구성 요소를 특정 책임에 집중함으로써 애플리케이션의 설계 및 유지 관리를 단순화합니다.
최적화: 명령과 쿼리를 분리하여 각 측면을 특정 요구 사항에 따라 독립적으로 최적화할 수 있습니다. 예를 들어, 명령 측은 쓰기가 많은 워크로드에 최적화되어 빠르고 일관된 데이터 업데이트를 보장할 수 있으며, 쿼리 측은 읽기가 많은 워크로드에 최적화되어 효율적인 데이터 검색 및 표시가 가능합니다.
확장성: CQRS를 사용하면 해당 작업 부하에 따라 명령 및 쿼리 구성 요소를 독립적으로 확장할 수 있습니다. 이러한 유연성을 통해 리소스 활용도를 높이고 성능을 조정하여 다양한 수준의 트래픽과 처리 요구 사항을 처리할 수 있습니다.
복잡한 도메인 처리: 데이터 모델이나 비즈니스 로직이 복잡한 복잡한 도메인에서 CQRS는 보다 표현력이 뛰어나고 유지 관리가 쉬운 솔루션을 제공할 수 있습니다. 이를 통해 개발자는 도메인의 특정 요구 사항에 맞게 명령 및 쿼리 모델을 맞춤화하여 두 가지 책임을 단일 모델에 맞추려고 할 때 발생할 수 있는 타협을 피할 수 있습니다.
이벤트 소싱 통합: CQRS는 또 다른 아키텍처 패턴인 이벤트 소싱과 함께 사용되는 경우가 많습니다. 이벤트 소싱에는 애플리케이션 상태에 대한 모든 변경 사항을 일련의 불변 이벤트로 캡처하는 작업이 포함됩니다. CQRS는 이벤트를 트리거하는 명령과 이를 사용하는 쿼리를 명확하게 구분하고 이벤트 기반 아키텍처를 촉진하며 변경 사항을 감사하고 재생하기 위한 강력한 메커니즘을 제공함으로써 이벤트 소싱을 보완합니다.
유연성: CQRS는 애플리케이션의 다양한 부분에 적합한 데이터 저장 메커니즘과 쿼리 모델을 선택할 수 있는 유연성을 제공합니다. 예를 들어, 명령 측에서는 트랜잭션에 최적화된 기존 관계형 데이터베이스를 사용할 수 있고, 쿼리 측에서는 읽기 작업이 많은 워크로드에 최적화된 NoSQL 데이터베이스 또는 복잡한 쿼리를 위한 특수 인덱싱 솔루션을 사용할 수 있습니다.
질문하신 내용을 개념에 대비해서 살펴보면 1,4번에 해당되는 것처럼 도메인 모델이 복잡해지는 것을 피하기 위해 단순 질의를 분리하면 유지보수성과 유연성이 높아 질 수 있습니다.
커맨드 와 질의 에 대한 서버분리를 질문하셨는데 2,3의 최적화와 확장성을 위해서는 각각의 서버(서비스)를 분리하는 것이 효과적이라고 생각합니다.
그리고 로직의 검증을 위한 조회나, 로직상 필요한 조회는 명령의 부분이라고 생각합니다.
감사합니다.