11장: CQRS

명령 모델과 조회 모델

• 조회할 때 여러 애그리거트에서 정보를 가져와야 하는데, 도메인마다 Repository를 따로 두고 사용하게 되면 JPA의 쿼리 최적화나 조인을 사용하는 등 조회 기술을 다양하게 사용할 수 없어 성능 상 문제가 발생할 수 있다.

• 시스템 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용해 문제가 발생한다. 객체 지향으로 도메인 모델을 구현할 때 사용하는 ORM 기법은 도메인 상태 변경 기능을 구현하는 데는 적합하지만 여러 애그리거트에서 데이터를 가져오는 기능에는 적합하지 않다.

• 상태를 변경하는 범위와 상태를 조회하는 범위가 정확하게 일치하지 않기 때문에 단일 모델로 두 종류의 기능을 구현하면 모델이 불필요하게 복잡해진다. 단일 모델을 사용할 때 발생하는 복잡도를 해결하기 위해 CQRS를 도입할 수 있다.

• CQRS란 Command Query Responsibility Segregation의 약자로 상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴이다.

• 도메인이 복잡할수록 명령 기능과 조회 기능이 다루는 데이터 범위에 차이가 나므로, 조회 모델을 별도로 만들어 다양한 성능 관련 기능을 모델에 적용할 수 있다.

• 조회 모델은 대체로 데이터를 읽어와 조회하는 단순한 기능을 구현하므로 응용 서비스 영역을 구현할 필요가 없다.

• 아래와 같이 상태 변경을 위한 명령 모델과 조회를 위한 조회 모델을 설계할 수 있다.

• 메모리에 캐싱 하는 데이터는 DB에 보관된 데이터를 그대로 저장하기보다는 화면에 맞는 모양으로 변환한 데이터를 캐싱 할 때 성능에 더 유리하다. 즉 조회 전용 모델을 캐시하는 것이다.

• 같은 개념의 도메인을 따로 두는 CQRS 패턴을 적용할 때 얻을 수 있는 장점은 명령 모델을 구현할 때 도메인 자체에 집중할 수 있다는 점이다.

• 도메인이 복잡하지 않은데 CQRS를 도입하면 두 모델을 유지하는 비용만 높아지고 얻을 수 있는 이점은 없다.