[EFUB 4기 BE Lead] 도메인 주도 개발 시작하기 - 11장. CQRS

EFUB 4기 BackEnd Lead_ 도메인 주도 개발 스터디

• 스터디 커리큘럼: 최범균, "도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지"
• 3주차 과제: Chapter 10. 이벤트, Chapter 11. 애그리거트 트랜잭션 관리

---

Chapter 11. CQRS

• Keywords: 명령 모델과 조회 모델, CQRS 장단점

11.1 단일 모델의 단점

시스템 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하면 성능에 문제가 생길 수 있고 구현이 복잡하다.

복잡도 낮추는 방법: 상태 변경을 위한 모델과 조회를 위한 모델을 분리하는 것.

11.2 CQRS

시스템이 제공하는 기능 (1) 상태 변경, (2) 상태 정보 조회.

상태를 변경하는 범위와 상태를 조회하는 범위가 정확하게 일치하지 않음. 복잡도 해결을 위해 CQRS를 사용 가능.

 

CQRS: 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴. 복잡한 도메인에 적합.

조회 모델을 이용해서 표현 계층에 데이터를 출력하고,

애플리케이션은 변경 요청을 명령 모델로 처리한다. 명령 모델이 도메인 로직을 실행한다.

도메인이 복잡할수록 명령 기능과 조회 기능이 다루는 데이터 범위에 차이가 나므로 분리하는 것이 굿.

 

명령 모델과 조회 모델은 서로 다른 기술을 이용해서 구현할 수 있다.

- 조회 모델 ex: DTO/DAO.

- 조회 모델은 응용 로직이 간단해서 응용 서비스가 없다. (구현하는 것도 가능하긴함)

- 둘다 JPA로 하는 것도 가능, 명령 모델은 JPA로 하고 조회 모델은 SQL로 하는 것도 가능

11.2.1 웹과 CQRS

웹 서비스: 조회 많이 함. 알게 모르게 CQRS를 적용하게 됨.

11.2.2 CQRS 장단점

명령 모델을 구현할 때 도메인 자체에 집중할 수 있음. 조회 성능을 위한 코드가 명령 모델에 없음->도메인 로직 구현에 집중, 명령 모델의 복잡도 낮아짐.

조회 성능 향상시키는 데 유리함.

 

단점: 구현해야 할 코드가 더 많음. 더 많은 구현 기술이 필요함.

도메인 복잡하지 않을 경우 두 모델을 유지하는 비용만 높아지고 얻을 수 있는 이점이 없음. 주의

반면 트래픽이 높은 서비스인데 단일 모델을 고집하면 유지 보수 비용이 오히려 높아질 수 있음.