주문 내역 조회 기능을 구현하려면 여러 애그리거트에서 데이터를 가져와야 한다.
•
Order에서 주문 정보
•
Product에서 상품 이름
•
Member에서 회원이름과 ID
조회 화면 특성상 조회 속도가 빠를수록 좋은데 여러 애그리거트의 데이터가 필요하면 구현 방법을 고민해야 한다.
3장에서 언급한 식별자를 이용해서 애그리거트를 참조하는 방식을 사용하면 즉시 로딩 방식과 같은 JPA의 쿼리 관련 최적화 기능을 사용할 수 없다. 이는 한번이 Select 쿼리로 조회 화면에 필요한 데이터를 읽어올 수 없어 성능에 문제가 생길 수 있다.
문제 발생 이유
•
시스템 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하기 때문 → ORM 기법은 Order#Cancel() 이나 Order#changeShippingInfo() 기능처럼 도메인 상태 변경 기능을 구현하는데 적합하다.
•
주문 상세 조회 화면처럼 여러 애그리거트에서 데이터를 가져와 출력하는 기능을 구현하기에 고려할 게 많아서 구현을 복잡하게 만든다.
해결 방법
•
상태 변경을 위한 모델과 조회를 위한 모델을 분리하는 것!
도메인이 복잡할수록 명령 기능과 조회 기능이 다루는 데이터 범위에 차이가 난다.
(NoSQL 같은경우 메모리 기반으로 조회 성능에 좋음)
구현방법
1.
명령 모델에서 데이터가 변경되면 조회 모델에 반영(동기 이벤트와 글로벌 트랜잭션을 사용) → 동기 이벤트와 글로벌 트랜잭션으로 전반적인 성능이 떨어진다.
2.
서로 다른 저장소의 데이터를 특정 시간 안에만 동기화 → 비동기로 데이터를 전송 ex) 통계 데이터
CQRS의 장단점
장점
1.
도메인 자체에 집중할 수 있다.
a.
복잡한 도메인은 주로 상태 변경 로직이 복잡한데 명령 모델과 조회 모델을 구분하면 조회 성능을 위한 코드가 명령 모델에 없으므로 도메인 로직을 구현하는데 집중할 수 있다. 또한 명령 모델에서 조회 관련 로직이 사라져 복잡도가 낮아진다.
2.
조회 성능을 향상시키는데 유리하다.
a.
조회 단위로 캐시 기술을 적용 할 수 있고, 조회에 특하된 쿼리를 마음대로 사용할 수 있다.
b.
조회전용 저장소를 사용하면 조회 처리량을 대폭 늘릴 수 있다.
c.
조회전용 모델을 사용하기 때문에 조회 성능을 높이기 위한 코드가 명령 모델에 영향을 주지 않는다.
단점
1.
구현할 코드가 많아진다.
2.
더 많은 구현 기술이 필요하다. 또한 데이터 동기화를 위해 메시징 시스템을 도입해야 할 수도있다.