https://github.com/choisooyoung-dev/d-ingco.git
한 줄 정리 : 펫시터와 고객을 매칭하며, 예약 관리 및 후기 확인이 가능한 페이지 프로젝트.
내용 : 내용 :
2-1. 공통 기능
2-2. 고객 기능
2-3. 펫시터 기능
1. 어떠한 문제에 마주할 때, 최소 1시간은 혼자 고민해보고 풀어보려고 노력할 것.
2. 서로 진도체크 하루에 1번씩 진행 18:00 시작.
3. 10:00 / 18:00시 오전 / 오후 회의 진행
4. 한명이라도 낙오 시 모두가 연대 책임( 시간제한 없음 )
5. 09:00 ~ 21:00 다른 조에 가서 놀지 말기 / 이 시간에는 가급적 최우선적으로 튜터님에게 질문할 것.
1. 모두가 낙오없이 개인과제 및 팀프로젝트를 완료하는것( 행복하진 않을 수 있음 ).
2. 팀 프로젝트 / 필수 구현가능한 기능 최우선적으로 완료.
3. 꺾이지 않고 끝까지 함께하기. ****
1. 10:00 / 18:00시 오전 / 오후 회의 진행
2. 매일 오후 18:00 현재 진행중인 진도 상황에 대한 공유.
3. 추후 개인과제 및 진도 미달성 인원 발생시 모두가 함께 강의 시청.( 화면 공유 )
"* 업무 분장이 아예 비어있네요. 내용을 채워주시길 바랍니다.
* 이한빛님은 빠르게 업무 마무리를 하셨네요. 좋습니다.
* 로그인 API에는 리퀘스트 헤더에 Bearer 토큰을 전달하는 것이 불가능합니다.
* 회원 삭제 API의 경우에는 리프레시 토큰을 같이 받아 혹여나 엑세스 토큰이 유출되었을 때 회원 삭제가 되지 못하도록 조치를 취해주세요.
* 회원 가입은 시터 회원가입과 별개로 두지 마시고 하나의 API로 관리를 한 후 role: ""user"", ""sitter""로 구분지어서 가입시키게 해주세요.
* ""sitter""의 경우에는 시터에 필요한 추가정보들만 리퀘스트의 바디로 던지면 됩니다.
* 전반적으로 일반 회원과 시터의 API가 이원화가 되어있는데 이것은 하나로 관리해주세요.
* 유저의 타입은 어차피 데이터베이스에서 조회가 되며 해당 타입에 맞게 입력값 유효성 검사를 진행해주시면 문제가 없습니다.
* 예를 들어, 시터인 경우에는 정보 수정 시 시터의 커리어를 입력할 수 있어야 하지만 유저인 경우에는 그럴 필요가 없죠.
* 이렇게 설계가 되면 유저와 시터외에 다른 role들이 추가될 때마다 API도 선형적으로 늘어나야 한다는 단점이 있습니다.
* type이 ""user""일 때 리퀘스트 헤더 포맷 & 리스폰스 포맷, ""sitter""일 때 리퀘스트 헤더 포맷 & 리스폰스 포맷이 API 문서에 명확히 기술이 되면 문제가 없습니다.
* ERD 피드백
* 유저와 펫시터는 하나의 유저 테이블로 관리를 해주시고 펫시터의 상세 정보는 유저 ID를 PK로 취급하여 테이블로 관리해주세요.
* 이 때 유저 테이블에는 role과 같은 역할을 구분지을 수 있는 컬럼이 필요합니다.
* 커리어 및 펫시터에 관련된 정보들만 펫시터의 상세 정보 테이블에 두세요.
* 이메일, 이름, 패스워드와 같은 항목들은 다 유저 테이블에 있으니 삭제를 해주셔야 됩니다.
* 펫 테이블이 생성이 안되었네요. 이 역시 유저 ID를 PK로 취급하여 테이블로 관리해주세요.
* 한명의 유저는 여러 반려동물을 보유할 수 있습니다. 유저 테이블에 pet 정보는 넣지 말아주시고 pets와 같은 테이블로 관리해주세요.
* 리저베이션과 리뷰의 관계는 1:1이 맞습니다. 잘하셨습니다!
* 리저베이션과 리뷰 테이블도 잘 작성은 하셨습니다만 리저베이션에 이미 의뢰인의 ID (유저 ID)가 들어가므로 리뷰에는 굳이 해당 컬럼이 필요하지 않습니다.
"
