객체지향책을 다시 읽으면서 깨달은 건, 좋은 설계란 단순히 클래스를 예쁘게 나누는 게 아니라 변경이 생겼을 때 덜 흔들리는 구조를 만드는 일이라는 점이다. 그래서 이제는 데이터보다 먼저 객체들이 어떤 행동을 하고 어떤 책임을 질지, 메시지는 어떻게 오갈지를 고민해 변경이 퍼지는 방향을 좁히는 쪽으로 설계하려 한다.

측정 데이터 목록 조회에서 최신 20건만 필요함에도 조인 순서 때문에 수집 로그 테이블에서 불필요한 읽기가 많이 발생하고 있었다는 문제를 STATISTICS IO/TIME으로 확인했습니다. 인덱스를 넣어 측정 테이블 읽기를 줄이고, 결국 먼저 20건을 뽑아서 그 결과만 로그와 대상자 테이블에 조인하는 구조로 바꿔 전체 logical reads를 약 98% 줄였습니다.

DDD 맥락에서 CQRS를 꼭 인프라 분리로 시작할 필요는 없다는 이야기입니다 — 쓰기와 조회의 관심사가 달라지며 서비스가 비대해질 때 같은 DB를 쓰더라도 CommandService와 QueryService로 책임을 분리해 코드를 더 명확하게 만들면 된다는 결론입니다.