[CQRS] CQRS는 언제/어디서 사용할까?

언제/어디서 사용할까?

여느 패턴과 마찬가지로, CQRS 역시 모든 시스템에서 항상 유용한 것은 아닙니다.

시스템을 작고 집중된 부분으로 분리하여 구조화하고 설계한 방식이 아니라면, 즉시 CQRS를 도입하는 것은 눈에 띄는 이점 없이 복잡성을 증가시킬 수 있습니다. 이 경우, 문제가 명확하고 작은 부분으로 분리될 수 있는 명확한 Boundary를 찾는 것부터 시작해야 하며, 보통의 경우 이런 Boundary를 찾아 관리하는 가장 좋은 방법은 DDD라고 이야기합니다.

즉, 시스템의 특정 부분에서만 CQRS를 적용하는 것이 좋으며 시스템 전체에서 사용하는 것은 권장하지 않습니다. DDD에서는 이런 시스템 특정 부분을 BoundedContext라고 이야기하며, 각 Bounded Context가 어떻게 모델링 되어야 하는지에 대한 결정 역시 필요합니다.

 

CQRS 패턴을 사용하는 것이 이점이 되는 경우는 아래와 같습니다.

• 여러 작업이 동일한 데이터에서 동시에 수행되는 공동 작업 도메인.(도메인 수준에서 병합 충돌을 최소화할 수 있을 정도로 자세하게 명령을 정의할 수 있습니다)
• 여러 단계를 거치거나 복잡한 도메인 모델을 사용하는 복잡한 프로세스를 통해, 사용자를 안내하는 작업 기반 사용자 인터페이스.(DDD에 익숙한 경우 유용합니다. 명령 모델과 쿼리 모델의 일관성이 유지됩니다)
• 데이터의 쿼리 성능을 데이터의 명령 성능과 별도로 세밀하게 조정해야 하는 시나리오.(시스템에서 쿼리 작업의 수가 명령 작업 수보다 몇 배이상 많은 경우, CQRS를 도입하여 쿼리 모델을 확장하고, 명령 모델은 하나 또는 소수의 인스턴스에서만 실행하는 것이 좋습니다. 이는 병합 충돌 발생을 최소화하는 데도 기여합니다)
• 시스템이 시간이 지남에 따라 변화할 것으로 예상되어 여러 버전의 모델을 포함할 수 있거나, 비즈니스 규칙이 정기적으로 변하는 시나리오
• 개발자 그룹을 나누어 일부는 복잡한 도메인 모델에 집중하고, 일부는 읽기 보델과 사용자 인터페이스에 집중할 수 있도록 구성된 시나리오

CQRS 패턴 적용을 권장하지 않는 경우는 아래와 같습니다.

• 도메인 또는 비즈니스 규칙이 간단한 경우
• 간단한 CRUD 스타일 사용자 인터페이스 및 관련된 데이터 액세스 작업으로 충분한 경우
• 전체 시스템에 구현하는 경우. (전체 데이터 관리 시나리오에서 CQRS가 유용할 수 있는 구성 요소가 존재하더라도, CQRS가 필요하지 않은 구성 요소에 대하여 불필요한 복잡성이 상당히 추가될 수 있기 때문입니다)

CQRS는 일반적인 시스템에서는 굳이 적용시킬 필요는 없고, Azure나 AWS 같은 클라우드 기반 서비스를 이용하면서, 확장성이 시스템의 핵심요소로 작용할 땐 반드시 고려해야 한다고 합니다. 최근 IT 트렌드가 클라우드 기반으로 바뀌어가고 있는 만큼 CQRS의 적용에 대한 부분은 반드시 생각해 보아야 할 가치가 있다고 여겨집니다.

 

다음 CQRS 파트에서는 기존의 전통적인 CRUD방식에 CQRS를 어떻게 적용하는 지에 대한 내용을 다루어 보도록 하겠습니다.