Yanabada_BEYanabada_BackEnd
안녕하세요, 멘토님!! 숙박 양도 상품 판매 프로젝트 팀 5조 야나바다 백엔드팀입니다.
먼저 서면으로 이렇게 리뷰 남겨주셔서 감사하다는 말씀드립니다.
저희는 2가지 면에서 멘토님의 의견을 듣고 싶습니다.
- 첫번째 저희 프로젝트 로직이나, 아키텍처, 설계중 실무에서는 기피하는 방식인데, 저희가 무분별하게 진행한 점이 있는지 여쭤보고 싶습니다.
- 설계 부분이나 진행상황중 저희가 놓친 점이나, 아니면 더욱 신경썼으면 좋겠는 점 여쭤보고 싶습니다.
저희는 숙박 양도상품 판매 서비스 이기 때문에 기본적인 더미데이터를 넣기 위한 API를 만들었습니다. DB에 쿼리로 넣기보다는 리스트로 묶어 API로 한번에 보내기 위함입니다. 따라서 Accommodation, AccommodationOption, Room, RoomOption 등록 API는 간소하게 작성했다는 점 미리 양해말씀드립니다. 한가지 추가적으로 궁금한 점이 있다면 POST 메소드 경우 서비스 단에서 void를 피하고 어떤 것이라도 반환값을 보내라고 들었는데, id정도만 보내도 될까요? 지금 더미 데이터를 넣기 위한 api의 서비스 메소드에선 void 이지만 controller 단에서 상태 성공 으로 BaseResponse를 보내긴합니다!
추운 겨울 감기 조심하시고, 행복한 한해 시작이 되시길 바랍니다! 감사합니다 멘토님!! 저희 상처 받는걸 좋아하니 적극 지적 부탁드리겠습니다^^ ㅎㅎㅎ
👋안녕하세요~ 야나바다 백엔드 팀입니다😀
박주현 | 안수지 | 장성수 | 황규철 |
---|---|---|---|
🏨 프로젝트 소개
프로젝트 내용
- 무료 예약 취소가 불가한 숙소의 양도/거래 플랫폼
프로젝트 주제 및 필수 구현 기능 제안
- 야놀자
프로젝트 제작 배경
- 예약 취소에 대한 불만이 많음, 유저의 착각/실수도 있으나 천재지변, 개인적 사유로 인해 어쩔 수 없이 취소수수료가 발생하는 경우 유저의 불만 및 탈퇴로 이어짐
- 예약 취소의 부정적 경험으로 인해 유저가 탈퇴하는 것을 막을 수 있는 방안으로 예약 취소 불가 상품을 해결할 수 있는 플랫폼 또는 기능 제공
- 공급자와 기존 구매자, 양도자를 모두 고려한 안전하고 신뢰도 높은 예약 취소 거래 기능 구축
- 예약 취소 수수료가 아닌 취소 예약건을 온전히 체크인 완료하면 매출 증대에 기여할 것으로 기대함
프로젝트 목적
- 기획, 디자인, 프론트, 백엔드 간의 협업
- RESTful API 개발
프로젝트 기간
- 서비스 기획 기간 : 2023년 12월 02일 ~ 01월 05일
- 서비스 개발 기간 : 2023년 01월 04일 ~ 01월 29일
프로젝트 실행방법
메뉴얼
야나바다 홈페이지
메인서버 배포 URL
테스트 서버 배포 URL
테스트 계정
- ID : test@naver.com
- PW : password123!
docker run -d -p 6379:6379 --name yanabada_redis redis
- 6379 포트로 Redis가 실행중이어야 프로젝트가 정상 실행됩니다!
- http://localhost:8080/h2-console 에 들어갑니다.
- 아래 정보대로 입력 칸을 채우고 Connect를 누른다.
- Driver Class: org.h2.Driver
- JDBC URL: jdbc:h2:mem:testdb
- User Name: sa
- Password: (빈칸)
📚 프로젝트 기술스택
🗺️ 프로젝트 파이프라인
🗄️서버 인프라
📝 프로젝트 기획
ERD
API 명세서
컨벤션
1. 코딩 컨벤션
- 커스텀 구글 코딩 컨벤션을 사용합니다.
- 메소드 네이밍, 패키지, DTO 네이밍 등 기타 코딩 컨벤션은 노션 백엔드 아카이브 폴더를 확인합니다.
2. 브랜치 전략 - Git Flow
- 브랜치 전략으로 Git Flow를 사용합니다.
- API 구현 및 설계는 모든 팀원의 Approve를 받아야 Merge 할 수 있습니다.
브랜치별 역할
- 실제 작업을 하는 브랜치
- 이슈 번호가 1이라면 feature/1로 만들면 됩니.
- 'develop'을 베이스 브랜치로 하여 만들어야 합니다.
- ( 브랜치 생성은 베이스 브랜치[ 체크아웃되어있는 브랜치 ]를 기준으로 만들어진다.)
- 작업이 완료되면 develop으로 Pull Request를 날립니다.
- 본인을 제외한 조원의 Approve를 모두 받았다면 Merge 합니다.
- 테스트 서버에 자동 배포되는 브랜치
- 다음 버전 개발을 위해 release으로 가기 전 기능 코드들을 모아두는 브랜치
- 작성한 기능이 잘 작동되는지 확인하고, release으로 PR 및 Merge를 하면 됩니다.
- develop으로 Merge 하고 나서 자동 배포된 테스트 서버에서 자신의 API가 정상 작동하는지 꼭 테스트해야 합니다.
- 실제 서비스를 운영할 수 있는 메인 서버 자동 배포되는 브랜치
- release으로 Merge 하고 나서 자동 배포된 메인 서버에서 자신의 API가 정상 작동하는지 꼭 테스트해야 합니다.
- 최종본을 갖는 브랜치
3. 협의사항
- 협업 관련
-
커밋 메시지 관련
- 커밋 제목은
prefix: 커밋 메시지
형태로 합니다. - prefix의 목록과 각각의 용도는 IntelliJ 플러그인 commit message template 에 맞춰 작성
- 커밋 내용을 자세하게 적습니다.
- 커밋 제목은
🤔 프로젝트 이슈
- 이슈기입
🪄 프로젝트 회고
박주현
취직하기 전에 4분야의 직무가 함께 하나의 프로젝트에서 협업해보는 소중한 경험이었습니다.
HTTP 프로토콜만 사용하는 REST API를 만들었는데, 채팅 도메인을 구현하면서 HTTP 이외의 다른 프로토콜을 사용한 API도 만들어보고 그게 실제로 정상 작동했을땐 매우 행복했습니다.
이번 프로젝트때 개인적인 목표로 3가지가 있었는데, 리버스 프록시 서버는 구현했지만 시간이 부족하여 무중단 배포와 Source - Replica Architecture를 도입해보지 못한게 아쉽습니다. 하지만 개인적으로 공부는 하였기에 다음번엔 도입해볼 수 있는 자신감도 얻었습니다.
1달이 넘는 시간동안 함께 고생한 PM분들, 디자이너분, 프론트엔드분들 그리고 백엔드 팀원들에게 감사함을 표합니다.