CQRS - Command and Query Responsibility Segregation

• 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가 훨씬 더 많다.

이벤트 소싱 패턴과 구체화된 뷰

• https://learn.microsoft.com/ko-kr/azure/architecture/patterns/event-sourcing
• https://learn.microsoft.com/ko-kr/azure/architecture/patterns/materialized-view