11장 CQRS

11. 1 단일 모델의 단점

• 시스템이 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하기 때문
• 객체 지향으로 도메인 모델을 구현할 때 주로 사용하는 ORM 기법은 도메인 상태 변경 기능을 구현하는 데는 적합하지만 주문 상세 조회 화면처럼 여러 애그리거트에서 데이터를 가져와 출력하는 기능을 구현하기에는 고려할게 많아서 구현을 복잡하게 만드는 원인이 됨

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

11.2 CQRS

• Command Query Responsibility Segregation
• 상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴
• CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있다.
• 명령 모델 : 객체지향에 기반해서 도메인 모델을 구현하기에 적당한 JPA,
  • 트랜잭션을 지원하는 RDBMS
• 조회 모델 : DB 테이블에서 SQL로 데이터를 조회할 때 좋은 마이바티스
  • 단순히 데이터를 읽어와 조회하는 기능은 응용 로직이 복잡하지 않기 때문에 컨트롤러에서 바로 DAO를 실행해도 무방하다.
  • 조회 성능이 좋은 메모리 기반 NoSQL

11.2.1 웹과 CQRS

• 웹은 쓰기 요청 보다 조회 요청의 빈도수가 높음
• 메모리에 캐싱하는 데이터는 DB에 보관된 데이터를 그대로 저장하기보다는 화면에 맞는 모양으로 변환된 데이터를 캐싱할 때 성능에 더 유리하다.

11.2.2 CQRS 장단점

장점

• 명령 모델을 구현할 때 도메인 자체에 집중할 수 있다는 점
• 조회 성능을 향상시키는 데 유리하다는 점

단점

• 구현해야할 코드가 더 많음
• 더 많은 구현 기술이 필요함

결론

• 도메인이 복잡하지 않은데 CQRS를 도입하면 두 모델을 유지하는 비용만 높아지고 얻을 수 있는 이점은 없다.
• 반면 트래픽이 높은 서비스인데 단일 모델을 고집하면 유지 보수 비용이 오히려 높아질 수 있으므로 CQRS 도임을 고려하자.