[REFACTOR] Recommendation 조회 응답 매핑 경계 정리

[Dimo-2562]

Parent: #419

✨ 리팩토링 할 부분

Recommendation 조회 use case의 application → presentation 역방향 의존을 제거하고 응답 매핑 책임을 명확히 한다.

🏷️ 도메인 (해당하는 것에 체크)

• 📝 domain:post (게시글)
• 👤 domain:useraccount (사용자 계정)
• 🧠 domain:personalization (개인화 프로필)
• 🏢 domain:source (테크블로그 출처)
• 🔍 domain:search (검색)
• 🔔 domain:notification (알림)
• 📊 domain:recommendation (추천)
• 🎯 domain:activity (사용자 활동)
• 🔐 domain:auth (인증/보안)
• 🌐 infra (인프라/배포)

📌 현재 코드의 문제점

• [REFACTOR] Recommendation 최상위 컨텍스트 패키지 승격 #452 / PR #455에서 계층별 물리 패키지가 드러난 뒤 RecommendationQueryService가 recommendation.presentation의 converter와 response DTO를 직접 참조하는 역방향 의존이 명확해졌다.
• RecommendationConverter는 북마크 상태가 null인 DTO를 만들고, application service가 같은 presentation DTO를 다시 조립해 북마크 상태를 채운다.
• application query 결과와 HTTP response 모델의 경계가 분리되지 않아 이후 RecommendationSet 도입 시 presentation 계약이 application/domain 모델에 섞일 위험이 있다.
• 현재 다른 최상위 컨텍스트의 application 패키지에는 presentation import가 없고 Recommendation만 예외다.

🎯 리팩토링 방향

• application query는 application 소유의 조회 결과/projection 또는 presentation과 무관한 결과를 반환한다.
• RecommendationListResponse, RecommendedPostDto 변환은 presentation 계층에서 완료한다.
• 북마크 상태 조합 책임을 application query result 생성 또는 presentation 변환 중 한 경계로 통일하고, null DTO 생성 후 재조립하는 흐름을 제거한다.
• RecommendedPost의 Post lazy relation을 presentation까지 노출하지 않도록 조회 트랜잭션 안에서 필요한 값을 projection/result로 고정한다.
• endpoint, JSON response shape, DB schema, 북마크 조합 결과는 유지한다.

✅ 완료 조건

• recommendation.application에서 recommendation.presentation import가 0건이다.
• 북마크 상태가 빠진 presentation DTO를 만든 뒤 application에서 다시 조립하지 않는다.
• RecommendationQueryServiceTest와 RecommendationIntegrationTest가 기존 응답 계약을 보호한다.
• [REFACTOR] RecommendationSet 개념 1차 도입 #422 RecommendationSet 및 [REFACTOR] Recommendation cross-context lookup 계약 고도화 #453 ID/projection 계약과 충돌하지 않는 조회 모델 경계를 선택한다.

순서

#452 패키지 승격 직후, #422 RecommendationSet 도입 전에 처리해 새 도메인 모델에 presentation 의존이 확산되지 않도록 한다.

💡 기대 효과

• 가독성 향상
• 성능 개선
• 유지보수성 향상
• 코드 중복 제거
• 기타: application → presentation 의존 역전 제거