CQRS는 복잡도가 생겼을 때만 선택한다

패턴 자체가 목표가 아니라, 읽기 모델 최적화와 쓰기 규칙 보호가 동시에 필요할 때 선택한다.

crud

단순 CRUD 비교

읽기와 쓰기 요구가 비슷하면 CQRS가 구조만 늘릴 수 있다.

command

Command 복잡도

상태 변경에 검증, 트랜잭션, 비즈니스 규칙이 몰리면 분리 가치가 커진다.

query

Query 불일치

조회 화면이 원본 모델과 멀어지고 캐시/색인이 필요하면 읽기 모델을 분리한다.

event

이벤트 동기화

쓰기 후 읽기 반영 지연을 허용할 수 있는지 먼저 정한다.

trace

추적 가능성

Command, Event, Query 흐름을 추적할 수 없으면 운영 위험이 커진다.

읽기 최적화가 쓰기 모델을 오염시키고 있는가?

비동기 반영을 사용자가 이해할 수 있는가?

장애 위치를 Handler, Event, Read Model로 분리해 찾을 수 있는가?