일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- spring boot
- ManyToOne
- 테이블 매핑
- event streaming
- OneToMany
- N:M
- JPA
- Event Drvien Architecture
- querydsl
- Event Messaging
- onetoone
- 다대다
- Today
- Total
차곡차곡 쌓아가는 개발일기
CQRS 패턴이란? 본문
CQRS패턴은 Command and Query Responsibility Segregation(명령과 조회의 책임 분리)를 의미한다.
용어 그대로 말해서 시스템에서 명령과 조회를 분리하는 것을 의미하는데, 여기서 명령은 시스템의 상태를 변경하는 것을 의미하며, 조회는 시스템의 상태를 반환하는 것을 의미한다.
기존 패턴에서는 데이터는 데이터베이스에서 레코드로써 다루어지고, 데이터들이 RDB에 레코드로 저장되기 위해서는 하나의 특정한 모델로 다루어지는데, 요구사항에서는 DB에서 저장하고 있는 레코드와는 다르게 데이터를 나타내거나 여러 레코드들을 결합하여 정보를 나타내는 등 저장된 데이터와 표현되는 데이터가 다를 수 있다.
그리고 모델이 변경되면 기존에 표현되던 데이터는 변질된 모델을 다시 가공해야하는 문제가 발생했다. 결국 개발자들은 모델의 생성, 수정, 삭제와 같은 명령 모델과 조회 모델을 분리하여 관리하게 되는데 이것이 CQRS 패턴이 등장하게 된 배경이다.
개발자는 일반적으로 모델의 핵심 요소를 담은 개념 모델을 구축하고, 도메인 모델을 사용하는 경우 이는 일반적으로 도메인을 개념적으로 표현한 것이다. 사용자는 위의 예시에서 Query Model을 통해 렌더링 된 웹 페이지를 보며, Command Model을 통해 변동 사항이 Query Model로 전달되어 업데이트된 상태를 렌더링한다.
CQRS는 어디에서나 적용하기 좋은 패턴일까
왜냐하면 CQRS는 복잡한 도메인 그것도 아주 소수의 도메인들에 대한 문제를 더 쉽게 해결하기 위한 하나의 방법일 뿐이며, 대규모 애플리케이션에서 명령과 조회를 분리함으로써 부하를 분산할 수 있으며 각각의 명령과 조회에 서로 최적화된 전략을 사용할 수 있기 때문에 사용하는 것이지 대다수의 위와 같은 상황이 아닌 일반적인 어플리케이션에서는 CRUD 패턴이 더 적합하다고 볼 수 있다.
CQRS를 적용하여 얻는 이점이 기존 시스템을 유지하는 것보다 크지 않다면 지양해야한다. 왜냐하면 명령과 조회를 분리함에 따라 시스템의 복잡도는 높아지고, 이는 소프트웨어를 심각한 문제로 빠뜨리기 쉽상이기 때문이다.
출처 마틴 파울러의 CQRS : https://martinfowler.com/bliki/CQRS.html