feat(be): add userChat DTO layer

[beekeeper24]

• add request/response DTOs for user chat messages and chat rooms
• update REST and WebSocket controllers to exchange DTOs instead of entities
• adjust chat message service signature so controllers pass DTO payload fields

test complete

[github-actions]

🤖 AI 리뷰 - src/main/kotlin/com/back/koreaTravelGuide/domain/userChat/chatmessage/controller/ChatMessageController.kt

🟢 좋은점:

• ApiResponse를 모든 API 응답에 일관되게 사용하며, 제네릭 타입(List, ChatMessageResponse)을 명확히 지정하여 타입 안전성을 높임. WebSocket 메시지(messagingTemplate.convertAndSend)에도 동일한 ApiResponse 형식을 적용해 클라이언트 측 일관성을 유지.
• Kotlin 최적화 측면에서 null safety를 잘 활용: @RequestParam(required = false) after: Long?와 if-else 조건문으로 null 케이스를 안전하게 처리. 또한, messages.map(ChatMessageResponse::from)처럼 함수 참조를 사용해 간결하고 함수형 스타일로 매핑 구현.
• ktlint 규칙 준수: 네이밍 컨벤션(예: camelCase 메서드명, 파라미터명)이 적절하고, 코드 포맷팅(들여쓰기, 줄바꿈)이 깔끔함. import 문도 필요한 것만 추가되어 불필요한 노이즈 없음.

🟡 개선사항:

• Kotlin 최적화: getMessages 메서드의 if-else 로직을 when 표현식으로 리팩토링하면 더 idiomatic하게 만들 수 있음. 예: val messages = when { after == null -> messageService.getlistbefore(roomId, limit); else -> messageService.getlistafter(roomId, after) }. 이는 코드 가독성을 높이고, 확장성(추가 조건 시)을 고려한 선택.
• sendMessage 메서드에서 req.senderId와 req.content를 직접 추출해 service.send 호출: 이는 DTO의 장점을 활용하지만, 서비스 레이어로 DTO 전체를 전달하는 방식으로 변경하면 컨트롤러가 더 얇아지고 책임 분리가 명확해질 수 있음 (예: service.send(roomId, req)).
• limit 파라미터의 기본값(50)을 상수로 정의하거나, 유효성 검사(@Min/@max 어노테이션 추가)를 고려: 현재는 기본값만 있지만, 과도한 limit 값으로 인한 성능 이슈를 방지할 수 있음.

🔴 문제점:

• 글로벌 익셉션 처리: 컨트롤러에 try-catch나 @ExceptionHandler가 없어 서비스 레이어 예외(예: roomId 유효

[github-actions]

🤖 AI 리뷰 - src/main/kotlin/com/back/koreaTravelGuide/domain/userChat/chatmessage/controller/ChatMessageSocketController.kt

🟢 좋은점:

• ApiResponse를 사용해 응답을 일관되게 감싸고 있으며, 변경 후에도 "메시지 전송" 메시지와 함께 DTO 기반 응답으로 유지되어 표준 응답 형식을 잘 지킴.
• Kotlin 최적화 측면에서 ChatMessageSendRequest와 ChatMessageResponse 같은 data class(추정)를 활용해 null safety와 간결한 데이터 전달을 강화했으며, ChatMessageResponse.from(saved)처럼 확장 함수를 사용한 변환 로직이 효율적임.
• ktlint 규칙 준수: 코드 포맷팅이 깔끔하고, 네이밍 컨벤션(예: camelCase, 의미 있는 변수명)이 적절함. 임포트 추가와 메서드 호출 변경이 간결하게 적용됨.

🟡 개선사항:

• 글로벌 익셉션 처리: WebSocket 핸들러(@MessageMapping)에서 예외가 발생할 수 있으므로, @ControllerAdvice를 통해 표준 에러 응답(ApiResponse 기반)을 명시적으로 처리하는지 확인 필요. 현재 코드에는 직접적인 try-catch가 없어, 서비스 레이어의 예외가 제대로 전파되는지 테스트 추천.
• Kotlin 최적화: req.senderId와 req.content를 직접 추출하는 대신, SendMessageReq를 유지하거나 확장 함수로 변환하면 더 유연할 수 있음. 또한, when 표현식을 활용해 roomId 유효성 검증을 추가하면 null safety를 강화할 수 있음.

🔴 문제점:

• 없음. 변경사항이 서비스 레이어와의 호환성을 고려한 구조적 개선으로 보이며, 필수 규칙을 위반하지 않음. 다만, 서비스의 send 메서드 시그니처 변경으로 인한 전체 코드베이스 영향(예: 다른 호출 지점)을 검토해야 함.

[github-actions]

🤖 AI 리뷰 - src/main/kotlin/com/back/koreaTravelGuide/domain/userChat/chatmessage/dto/ChatMessageResponse.kt

🟢 좋은점:

• Kotlin data class를 적절히 사용해 불변성과 equals/hashCode/toString을 자동으로 제공하며, DTO로서의 역할을 잘 수행함. 이는 Kotlin 최적화 규칙을 준수.
• null safety가 잘 적용됨: id는 Long?으로 nullable 처리 (엔티티 생성 시 ID가 없을 수 있음), 나머지 필드는 non-nullable로 명확히 정의.
• companion object의 from() 함수가 간단하고 직관적이며, 엔티티를 DTO로 변환하는 패턴을 잘 따름. ktlint 규칙(포맷팅, 네이밍 컨벤션)에 위배되지 않음.

🟡 개선사항:

• from() 함수를 companion object 대신 확장 함수로 변경 고려: fun ChatMessage.toResponse() = ChatMessageResponse(...). 이는 Kotlin의 idiomatic 스타일로 더 유연하고 체이닝 가능하게 만듦.
• createdAt 필드의 Instant 타입이 API 응답에서 직렬화 시 UTC 기준으로 처리될 수 있으니, 클라이언트 요구사항에 따라 LocalDateTime으로 변경하거나 @jsonformat 어노테이션 추가를 검토 (Kotlin 최적화 측면에서 null safety는 유지하되, 시간 형식 최적화).

🔴 문제점:

• 없음. 코드가 안정적이고 규칙을 모두 준수함.

[YangHJ2415]

확인했습니다!