일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- AWS101
- 자바
- 자바8
- 클린코드
- Java
- 스트림
- 자바의 신
- Stream
- spring Batch
- domain
- web
- facade pattern
- head first
- Clean Code
- jsp
- spring boot
- Java8
- 자바8인액션
- SERVLET
- 패스트캠퍼스
- Java 8 in action
- Java8 in action
- CQRS
- ddd
- Java in action
- Was
- spring
- 디자인 패턴
- Design Pattern
- Template Method Pattern
- Today
- Total
주난v 개발 성장기
[DDD START!] 11장. CQRS 본문
CQRS - Command Query Responsibility Segregation
단일 모델의 단점
조회 화면의 특성상 속도가 빨라야 하는데, 여러 애그리거트에서 데이터를 가져와야 할 경우 구현 방법을 고민해야 한다.
(ex. 주문 상세 조회 시에 주문, 상품, 회원 정보를 모두 조회해한다.)
ID를 이용해서, 애그리거트를 참조하는 방식을 사용하면 즉시 로딩과 같은 최적화 기능을 이용 못하고, 여러번 select를 해야함으로 속도에 문제가 생긴다.
ID가 아니라 직접 참조하는 방식으로 연결해도 즉시 로딩이나 지연 로딩을 처리해야 하므로, 네이티브 쿼리를 사용해야 할 수도 있다.
이러한 고민은 단일 도메인을 사용하기 때문이다.
해결법은 상태 변경을 위한 모델과 조회를 위한 모델을 분리하는 것!
CQRS
시스템이 제공하는 기능은 크게 2가지
- 상태 변경
- 조회
상태 변경은 주로 한 애그리거트의 상태를 변경
조회는 최소 한 개 ~ N개의 애그리거트에서 데이터를 조회할 수도 있다.
상태를 변경하는 범위와 조회를 하는 범위가 일치하지 않기 때문에, 단일 모델로 두 종류의 기능을 구현하면 복잡해진다.
(사실 책에서는 이렇게 설명해주지만, 복잡할 정도의 도메인을 구현해본적은 없기에...공감 정도만..)
CQRS - 상태를 변경하는 명령을 위한 모델과 조회를 위한 모델을 분리하자.
CQRS는 복잡한 도메인에 적합하다.
도메인이 복잡할수록 명령 기능과 조회 기능이 다루는 데이터 범위에 차이가 발생한다.
--> 단일 모델로 처리하게 되면 조회 기능의 로딩 속도를 위해 모델 구현이 필요 이상으로 복잡해 진다.
(옵션들이 추가된다는 말인것 같음)
CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있다.
상태 변경 - 도메인 모델 구현 (JPA)
상태 조회 - MyBatis(DAO)
명령 모델은 상태를 변경하는 로직에 초점
조회 모델은 조회하는 데에 초점
물론, 명령 모델과 조회 모델이 같은 구현 기술을 사용할 수 있고, 이에 대한 내용은 5장에서
- JPQL을 이용한 동적 인스턴스 생성
- 하이버네이트 @Subselect를 이용
2가지로 설명함.
그리고... 개발을 하다보면
명령 모델은 트랜잭션을 지원해 주는 RDBMS, 조회 모델은 조회 성능이 좋은 NOSQL 사용도 가능할 수 있다.
두 데이터 동기화는 이벤트로 처리하고, 명령 모델에서 데이터가 바뀌자마자 변경 내역을 조회 모델에 반영해야 한다면, 동기 이벤트와 글로벌 트랜잭션을 사용.
하지만 속도가 감소한다.
이런 케이스가 아니라면 비동기로 데이터를 전송한다.
* Tip - CQRS 패턴을 적용하기 위해 반드시 사용해야 할 기술이 존재하는 것은 아니다.
조회는 직접 SQL(@Query)로 구현하고, 명령 모델은 JPA로 구현할 수 있다.
웹과 CQRS
일반적인 웹 서비스는 상태 변경보다 조회 요청이 훨씬 많다.
따라서, 메모리에 조회 데이터를 캐시하거나 조회 전용 저장소를 따로 사용하기도 한다.
대규모 트래픽 서비스에는 CQRS가 대부분 적용되어 있다.
단지 조회 모델과 명령 모델을 구분하지 않았을 뿐.
단 조회 속도를 높이기 위해 별도 처리를 하고 있다면 모델을 구분하자.
이를 통해 모델이 복잡해지는 것을 방지할 수 있다.
CQRS 장단점
장점
1. 명령 모델과 조회 모델을 분리하면, 조회 성능을 위한 코드가 명령 모델에 없으므로 도메인 로직 구현에 집중 가능하고 복잡도를 낮춘다.
2. 조회 성능 향상하는데 유리함. (조회 단위로 캐시를 적용하거나, 특화된 쿼리를 사용 할 수 있다. 또한 조회 전용 저장소 사용, slave)
단점
1. 구현해야 할 코드가 더 많다.
구현 비용을 따져봐야 한다.
도메인이 복잡하거나 대규모 트래픽이 발생하는 서비스라면 조회 전용 모델을 만드는 것이 향후 유지보수에 유리하다.
2. 많은 구현 기술이 필요하다.
명령 모델과 조회 모델을 다른 구현 기술을 사용해서 구현하기도 하고, 경우에 따라 다른 저장소를 사용하기도하고, 메시징 큐를 이용하기도 한다.
이를 모두 종합적으로 판단해보고, CQRS 도입을 결정해보자.
'개발 성장기 > DDD' 카테고리의 다른 글
[DDD START!] 10장. 이벤트 (0) | 2020.06.09 |
---|---|
[DDD START!] 9장. 도메인 모델과 BOUNDED CONTEXT (0) | 2020.06.08 |
[DDD START!] 8장. 애그리거트 트랜잭션 관리 (1) | 2020.06.02 |
[DDD START!] 7장 도메인 서비스 (0) | 2020.05.29 |
[DDD START!] 6장. 응용 서비스와 표현 영역 (1) | 2020.05.26 |