Feature/#19 api response

[CDHyun]

🔍 변경 사항

이번 PR에서 변경된 핵심 내용을 간단히 설명해주세요.

• BE BaseResponse 정의
  • CommonResponseCode 정의
• ERD에 대응되는 Entity 정의
• Home 화면에 필요한 다가오는 초대, 최신 게시물 Response 정의

🔗 관련 이슈

해당 PR과 연결된 이슈 번호를 적어주세요. (예: #1)

• 백엔드 응답 구조 정의 #19

✅ 체크리스트

• 팀 컨벤션을 준수했나요?
• 불필요한 주석이나 import는 삭제했나요?

리뷰 요청

D-Day 계산은 어디서 할 것인지?

오늘 팀 회의에서 깜빡하고 말씀을 못 드렸던 부분이 있어서 남깁니다!

저희 다가오는 초대나 초대장 리스트 등에서 D-Day를 보여주는 기능이 있습니다.
이 부분을 서버에서 계산해서 내려줄 것인지, 클라이언트에서 계산할 것인지를 정하면 좋을 것 같습니다!

data class UpcomingInvitationResponse(
    val id: Long,
    val title: String,
    val hostName: String,
    val startTime: LocalDateTime,
    val thumbnailUrl: String,
    val dDay: Int
)

현재는 Response에 D-Day 필드까지 넣어놓은 상태인데,
정해지는 방향에 따라서 변경하도록 하겠습니다.

Entity 분리를 하는 것이 좋을지?

현재는 하위 Entity를 분리하지 않고 부모 Entity 밑에 선언해뒀습니다. (GuestBook 하위에 GuestBookVideo 등)
이 부분을 외부 파일로 분리하는 것이 좋을지 현재 형태도 괜찮을지 의견 주시면 감사하겠습니다.

리스트형 필드에 대한 대응

@Converter
class StringListConverter : AttributeConverter<List<String>, String> {

    private val splitChar = ","

    // 엔티티의 List를 DB에 넣을 String으로 변환 (List -> "url1,url2")
    override fun convertToDatabaseColumn(attribute: List<String>?): String? {
        return attribute?.joinToString(splitChar)
    }

    // DB에서 가져온 String을 엔티티의 List로 변환 ("url1,url2" -> List)
    override fun convertToEntityAttribute(dbData: String?): List<String> {
        return dbData?.split(splitChar)?.filter { it.isNotBlank() } ?: emptyList()
    }

}

필드에 리스트형식으로 데이터가 들어가야 하는 필드가 있습니다.
MySQL에서 5.7 버전부터 JSON 형식으로 저장이 가능한 것으로 알고 있는데,
지금 형태 (리스트 -> 문자열 -> 문자열로 저장 -> 문자열 불러옴 -> 리스트로 변환)를 유지하는 것이 좋을지
JSON 형태로 저장하는 것이 좋을지 의견을 주시면 감사하겠습니다.