CQRS 패턴

CQRS는 데이터 저장소에 대한 읽이 및 업데이트 작업을 구분하는, 명령(command)과 쿼리(query)의 역할(responsibility) 분리. 애플르케이션에서 CQRS를 구현하면 성능, 확장성 및 보안을 최대화할 수 있다.

• 유연성이 생김
• 시스템이 점점 진화하고 업데이트 명령이 domain 수준에서 병합 충돌을 일으키지 않게 한다.

컨텍스트 및 문제점

• 기존 아키텍처하지만 애플리케이션이 더 복잡해지면 이 방법을 사용하기 어려울 수 있다. 예를 들면 하나의 dto에서 읽는 작업하고 수정하는 작업으로 모두 사용한다면 쓰기 작업에서는 많은 유효성 검사와 비즈니스 로직을 구현될 가능성이 있기 때문에 복잡한 모델이 될 수 있다.
• 데이터베이스를 쿼라하고 업데이트하는 데 동일한 데이터 모델을 사용한다. 이것은 간단하고 기본적은 CRUD 작업에 적합하다.
• 문제점
  • 데이터의 읽기와 쓰기 사이에 불일치가 나타나는 경우가 있을 수 있다.
  • 동일한 데이터 세트에서 작업을 병렬로 수행할 때 데이터 경합이 발생할 수 있다.
  • 엔티티 각각이 읽기와 쓰기 작업의 대상으로 잘못된 컨텍스트에 따라 데이터를 노출시킬 수 있어서 보안 관리가 복잡해진다.

해결 방법

CQRS 패턴으로 명령 및 데이터를 읽는 쿼리 dto를 다른 모델로 구분한다.

• 명령(수정)은 데이터 중심이 아닌 작업을 기반으로 해야 한다.
• 명령은 동기적으로 처리되지 않고 비동기 처리를 위해 큐에 배치될 수 있다.
• 쿼리는 데이터베이스를 수정하지 않는다. 그리고 도메인 정보를 캡슐화하지 않는 dto를 반환한다.

이점

• 독립적인 크기 조정 및 읽기, 쓰기 워크로드를 독립적으로 확장하고 더 적은 수의 잠금 경합이 발생할 수 있다
• 최적화된 스키마를 사용. 읽기 쪽에서는 쿼리에 최적화된 스키마를, 쓰기 쪽에서는 쓰기에 최적화된 스키마를 사용
• 관심사의 분리. 읽기 및 쓰기 쪽을 구분하면 유지 가능하고 유연한 모델을 생성할 수 있다. (대부분은 쓰기보다 읽기가 더 간단함)

CQRS가 필요하지 않은 경우

• 도메인 또는 비즈니스 규칙이 간단한 경우
• 간단한 CRUD 스타일 사용자 인터페이스 및 데이터 액세스 작업이 충분한 경우