단일 모델의 단점
- 조회 화면 특성상 조회 속도가 빠를수록 좋은데 여러 애그리거트의 데이터가 필요하면 구현 방법을 고민해야 한다.
- ORM 기법은 도메인 상태 변경 기능을 구현하는 데는 적합하지만 여러 애그리거트에서 데이터를 가져와 출력하는 기능을 구현하기에는 고려할 게 많아 구현을 복잡하게 만드는 원인이 된다.
- 상태를 변경하는 범위와 상태를 조회하는 범위가 정확하게 일치하지 않기 때문에 단일 모델로 두 종류의 기능을 구현하면 모델이 불필요하게 복잡해진다.
CQRS(Command Query Responsibility Segregation)
- 상태를 변경하는 명령(Command)을 위한 모델과 상태를 제공하는 조회(Query)를 위한 모델을 분리하는 패턴
- 명령 모델은 상태를 변경하는 도메인 로직을 수행하는 데 초점을 맞춰 설계, 조회 모델은 화면에 보여줄 데이터를 조회하는 데 초점을 맞춰 설계
- CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있다. 예를 들어 명령 모델은 객체지향에 기반해서 JPA를 사용해서 구현하고, 조회 모델은 DB 테이블에서 SQL로 데이터를 조회할 때 좋은 MyBatis를 사용해서 구현하면 된다.
- 명령 모델과 조회 모델이 서로 다른 데이터 저장소를 사용할 수도 있다. 명령 모델은 트랜잭션을 지원하는 RDBMS를 사용하고, 조회 모델은 조회 성능이 좋은 메모리 기반 NoSQL을 사용할 수 있다. 두 데이터 저장소 간 데이터 동기화는 이벤트를 활용해서 처리한다.
웹과 CQRS
- 일반적인 웹 서비스는 상태를 변경하는 요청보다 조회하는 요청이 많다.
- 조회 성능을 높이기 위해 다양한 기법을 사용하는 것은 결과적으로 CQRS를 적용하는 것과 같은 효과를 만든다.
- 조회 속도를 높이기 위해 별도 처리를 하고 있다면 명시적으로 명령 모델과 조회 모델을 구분하자. 이를 통해 조회 기능 때문에 명령 모델이 복잡해지는 것을 막을 수 있고, 명령 모델에 관계없이 조회 기능에 특화된 구현 기법을 보다 쉽게 적용할 수 있다.
CQRS 장점
- CQRS 패턴을 적용하면 명령 모델을 구현할 때 도메인 자체에 집중할 수 있다. 또한 명령 모델에서 조회 관련 로직이 사라져 복잡도가 낮아진다.
- 조회 성능을 향상시키는데 유리하다. 조회 단위로 캐시 기술을 적용할 수 있고, 조회에 특화된 쿼리를 마음대로 사용할 수도 있다. 캐시뿐만 아니라 조회 전용 저장소를 사용하면 조회 처리량을 대폭 늘릴 수도 있다.
- 조회 전용 모델을 사용하기 때문에 조회 성능을 높이기 위한 코드가 명령 모델에 영향을 주지 않는다.
CQRS 단점
- 구현해야 할 코드가 많다. 도메인이 복잡하거나 대규모 트래픽이 발생하는 서비스라면 조회 전용 모델을 만드는 것이 향후 유지 보수에 유리하다. 반면 도메인이 단순하거나 트래픽이 많지 않은 서비스라면 좀 더 고려해봐야 한다.
- 더 많은 구현 기술이 필요하다. 명령 모델과 조회 모델을 다른 구현 기술을 사용해서 구현하기도 하고 다른 저장소를 사용하기도 한다. 또한 데이터 동기화를 위해 메시징 시스템을 도입해야 할 수도 있다.
Reference
Comments