[DISCUSSION] Reservation및 Matching DTO 수정에 대한 논의

LineNo2 commented 1 year ago

내용

현재 클라이언트에서 수신하는 DTO는 다음과 같다.

MatchingModel

{
            "id": "6503b645b723d27a6739687a",
            "seating": 3,
            "startTime": "2023-09-15T01:41:25.286",
            "cafeSummaryDto": {
              "id": "64fd48821a11b172e165f2fd",
              "name": "스타벅스 테헤란로아남타워점",
              "address": "아남타워빌딩 1층",
              "imageUrl": "https://picsum.photos/50/50"
            }
          }

ReservationModel

{
            "reserveId": "6503b645b723d27a6739687a",
            "reserveStartTime": "2023-09-15T01:41:25.286",
            "reserveEndTime": "2023-09-15T11:41:25.286",
            "matchingSeating": 3,
            "cafeSummaryDto": {
              "id": "64fd48821a11b172e165f2fd",
              "name": "스타벅스 테헤란로아남타워점",
              "address": "아남타워빌딩 1층",
              "imageUrl": "https://picsum.photos/50/50"
            }
}

둘이 비슷한 내용을 가지고 있음에도 불구하고, 균일하지 않은 느낌을 받을 수 있다. 이렇게 되면 프론트에서 두가지의 모델을 활용해 로직을 구성할 때 같은 코드를 두번 작성하게 되는 슬픈 일이 생길 수 가 있다. 이에 두 DTO의 형식 변경을 제안하는 바이다.

제안

{
            "id": "6503b645b723d27a6739687a",
            "headCount": 3,
            "startTime": "2023-09-15T01:41:25.286",
            "endTime": "2023-09-15T01:41:25.286",
            "cafeSummaryDto": {
              "id": "64fd48821a11b172e165f2fd",
              "name": "스타벅스 테헤란로아남타워점",
              "address": "아남타워빌딩 1층",
              "imageUrl": "https://picsum.photos/50/50"
            }
          }

여기에 추가로 만약 두가지의 구분이 필요하다면 type 속성을 넣는 것도 방법이 될 수 있겠지만, 사실 다른 엔드포인트로 요청해서 받아오는 것이기 때문에 딱히 구분해줄 필요는 없을 것 같긴하다. headCount로 바꾼것은 어떻게든 멋있는 이름을 찾아보다가 정하게 되었는데, 이 부분은 사실 어떻게 와도 관계가 없긴 하다. MatchingModel의 경우는 endTime속성이 필요 없으므로 그냥 안받으면 될 것이다. 이렇게 되면 프론트에서는 같은 로직을 짜서 재활용하기가 훨씬 편해진다.

isayaksh commented 1 year ago

MatchingModel

{
    "id": "6503b645b723d27a6739687a",
    "seating": 3,
    "startTime": "2023-09-15T01:41:25.286",
    "cafeSummaryDto": {
        "id": "64fd48821a11b172e165f2fd",
        "name": "스타벅스 테헤란로아남타워점",        
        "address": "아남타워빌딩 1층",
        "imageUrl": "https://picsum.photos/50/50"
        }
}

ReservationModel

{
    "id": "6503b645b723d27a6739687a",
    "seating": 3,
    "startTime": "2023-09-15T01:41:25.286",
    "endTime": "2023-09-15T11:41:25.286",
    "cafeSummaryDto": {
        "id": "64fd48821a11b172e165f2fd",
        "name": "스타벅스 테헤란로아남타워점",
        "address": "아남타워빌딩 1층",
        "imageUrl": "https://picsum.photos/50/50"
    }
}

위와 같이 DTO를 변경하는 것은 100% 찬성입니다. headCount 필드를 추가하는 것은 어렵지 않은 작업이지만 필요성에 대해서는 @psy-choi 님과 함께 이야기 해봐야할 것 같습니다.

psy-choi commented 1 year ago

이름을 동일하게 가는 것을 괜찮을 것 같습니다. seating -> headcount 꼭 필요하다고 느낀다면 괜찮지만, 실제로 저장되어 있는 DB의 칼럼이 seating이라서 개인적으로 seating으로 가는 것이 좀 더 선호하기는 합니다.

다만, 저 두 개의 DTO를 하나의 DTO로 통합한다는 것을 다른 이야기가 될 것 같아요. 실제로 저희 활동 시나리오에는 예약 기능에 메뉴도 포함할 수 있다는 점과 같이 실제로 나의 예약/매칭 기록이 확장성 있게 달라질 수 있는 가능성도 있어요. 그렇기 때문에 DTO를 하나로 만드는 것은 조금 위험하지 않을까 싶습니다.

일단은 두 DTO 의 key 이름을 동일하게 만드는 것은 동의합니다!

LineNo2 commented 1 year ago

headCount를 굳이 사용하지 않아도 괜찮습니다. 사실 어느 값으로 받든 상관은 없습니다. 요는 두 DTO의 키값이 호환되는 정도가 되면 좋겠다 입니다지, 무리해서 바꾸시거나 그럴 필요는 없을 것 같습니다. 심지어 DB에 이미 다른 값으로 저장이 되어있다면, 굳이 수고를 안하셔도 될 것 같습니다. 나머지 부분의 키값이 어느정도 통일만 된다면 제가 작업하기 정말 편해질 것 같습니다.

LineNo2 commented 1 year ago

회의 결과

유저앱의 프론트엔드단에서 인터페이스를 활용하는 것으로 결정되었습니다. 이유는 다음과 같습니다.

이미 점주앱 프론트단에서는 해당 DTO로 작업이 완료되어있음.

프론트에서 인터페이스를 활용하면 의도대로 구현이 가능함.

이와같은 이유로 백엔드 서버에서의 수정 없이, 프론트엔드가 인터페이스를 활용해 key값의 이름만을 변경하는 것으로 결정되었습니다.

SWM-99-degree / jariBean