martinfowler.com/bliki/CQRS.html  (번역)

https://martinfowler.com/bliki/CommandQuerySeparation.html

 

CRUD를 모두 하나의 도메인 모델을 사용해 처리했었다면,

CQRS는 CUD를 Command용 모델로, R을 Query용 모델로 분리하여 설계하는 방법

 

하지만 문서 전체에서 CQRS는 잘 들어맞는 부분에만 일부 사용할 것을 권장하고 있다.

 

문서에서 발췌

CQRS는 시스템의 특정한 부분(DDD 표현으로는 Bounded Context)에서만 사용돼야 하고, 시스템 전체에서 사용해서는 안 된다.

이러한 사고방식은 각 Bounded Context는 개별적으로 모델링을 해야 한다는 의미다.

(Bounded Context: https://www.martinfowler.com/bliki/BoundedContext.html)

 

많은 정보 시스템들은 정보를 기반으로 한가지 방식으로 읽기와 쓰기를 하는 것에 잘 맞는데, 여기에 CQRS를 더하는 건 불필요한 복잡성을 늘릴 뿐이다.

 

취해야 할 것

  • 하나의 요청(API든, method call이든) 에서 Command와 Query를 분리한다는 컨셉 자체는 언제든 차용할만 함.
    • 이건 기존에도 분리해서 설계하는게 좋은 설계이긴 했음.
    • Query면 Query이고 Command면 Command인 편이 명확하다.
    • Query + Command라는, Query인 줄 알았는데 side-effect를 만드는 작업은 보통 이렇게 묶지 않는 것이 좋다.
  • 하지만 분리가 불가능하거나, 분리하면 더 어색한 경우가 분명 있으므로 상황에 맞게 적용이 필요하다.

 

성능 관점에서

they may also use separate databases, effectively making the query-side's database into a real-time ReportingDatabase.

 

  • 쓰기에 비해 읽기 워크로드가 상당히 큰 경우, 쓰기DB와 읽기전용 DB를 분리하는 것이 이득인 경우가 있다.
  • 이 때 읽기 워크로드가 크다는 것은 (항상 그런 것은 아니지만) 읽기 전용 Domain Model 분리를 검토해볼 수 있다는 시그널이며, 분리하게 되면 읽기전용 DB와 상호작용하는데 보다 더 자연스럽다.
  • CQRS의 좋은 예는, 페이스북 같은 feed 시스템이다. post에 비해서 feed가 훨씬 더 많다.