[DDD, 도메인 주도 개발] 11.CQRS(Command and Query Responsibility Segregation)

CQRS

여러 애그리거트의 데이터가 필요한 조회 기능을 개발 할 때 조회 속도 개선과 함께 구현 방법에 대한 고민이 많아진다.

 

식별자 참조, 직접참조 등.. 객체 지향으로 도메인 모델을 구현할 때 주로 사용하는 (JPA와 같은)ORM 기법은 도메인 상태 변경 기능을 구현하는 데는 적합하지만 여러 애그리거트에서 데이터를 가져올 때는 고려할 게 많아 구현을 복잡하게 한다.

 

도메인 모델 관점에서 상태 변경 기능은 주로 한 애그리거트의 상태를 변경한다. 

조회 기능은 애그리거트가 두 개 이상 필요할 때가 많다.

단일 모델로 두 기능을 구현 하면 불필요하게 복잡해진다.

 

CQRS 는 상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴이다.

 

• 각 모델에 맞는 구현 기술을 선택할 수 있다.
  • 조회용은 JPA대신 MyBatis를 사용하기,  조회 성능이 좋은 메모리 DB를 사용하는 등.
  • 명령/조회 모델용 데이터 동기화는 이벤트등을 통해 처리 할 수 있다.
• 단순 조회의 경우 응용서비스를 만들지 않아도 된다.
• 일반적인 웹서비스는 쿼리최적화, 메모리캐싱등 조회 성틍 개선을 위한 다양한 기법을 사용하는데 이도 CQRS를 적용하는 것과 비슷하다. -> 명시적으로 명령 모델과 조회 모델을 구분해 복잡도를 낮추는 것이 좋다.

[CQRS 장점]

• 조회 성능을 위한 코드가 명령 모델에 없으므로 명령 모델을 구현 할 때 도메인 자체에 집중할 수 있다.
• 조회 성능을 향상시기는 데 유리하다.  -> 조회 특화용 기술 적용 용이

[CQRS 단점]

• 구현 코드량이 늘어남 
• 더 많은 구현 기술이 필요하다. (여러 저장소나 데이터 동기화를 위한 메시징 시스템 도입등)

유지보수 비용이나 장단점을 잘  고려해서 CQRS패턴 도입 여부를 결정하자.

 

 

Reference

도메인 주도개발 시작하기, 최범균 저