•
배포 계획
◦
프론트 정적 웹 서버: AWS S3 + CloudFront
◦
백엔드 웹 앱 서버: AWS EC2 + RDS + ElasticCache + ALB
◦
CI/CD: 미정
•
이번 주 한 일
◦
기획 및 기획 개편
◦
개발 환경 설정
◦
ERD, Wireframe, APi명세서 작성 완료
◦
git projects 를 이용하여 일정 및 진행도 공유
◦
팀원 개인
정성호(팀장)
김진훈
김민중
김혜윤
•
이외에도 기술적인 방향을 잡기 위한 질문을 정리해두시면 가장 좋습니다!
→ 단, “A는 어떻게 구현하나요”의 질문은 삼가주세요.
→ “A와 B를 알아보았는데, 둘 중 A가 낫다고 판단했는데 맞을까요?”의 식의 고민의 흔적을 담아 질문해주세요.
◦
현재 Seat table 와 place table 가 구분되어 있는데, seat table를 단독으로 사용하지 않는 상황에서 구분할 필요성이 있을까요? → 이대로 하자~
◦
/api/v1/places/{placecId}/goods/{goodsId}/sequences/{sequenceId}/seats/{seatId}
이 순서? 이렇게 작성하는 것이 맞을까요? → 이건 너무해…. 복합키로서 필요한 것만 쓰자;;;
→ 만약 어떤 메소드가 goodId가 필요하다면, 그거는 queryparameter로
◦
dto → entity 변환 시
1) User of(String email, String password…),
2) User of(UserCreateRequest)
entity는 request에 의존하지 않고 그 자체로 존재해야 한다고 생각
Request.toEntity(User) → User of(String email, String password…)
튜터님의 의견은? 궁금합니다? 저희는 User.of(request) 방식으로 결정했습니다.
이 부분의 이후 문제점을 발견, Sequence 같은 경우 request가 필요하지 않는데 이것을 통일화하기 위해서는 SequenceRequest를 만들어야 하는데 불필요한 request dto인데 맞는 것일까?
→ 하지만, 한 팀원의 의견(익명성 보장)은 굳이 entity를 생성하는 부분에서 이 request를 파라미터로 전달하는 부분이 꼭 모든 부분에서 통일화가 되어야 하는가? request를 전달하는 방식을 사용하자는 것은 개발의 편의성, 변경 가능성을 고려해서 적절한 방식을 혼용해서 사용하는 것이 어떤가입니다.
→ 이 request를 파라미터로 전달하는 방식과 필드를 파라미터로 전달하는 방식을 혼용해서 사용하는 것이 코드 내 통일성(= 컨벤션)을 위배하는 것인가? 에 대한 의견이 궁금합니다. → 저는 코딩 컨벤션이라는게 entity의 생성방식을 고정하는 것은 아니라고 생각하는데..
튜터님 한 말씀 ✅
request.toEntity() → Entity.builder().build
builder 패턴?
Plain Text
복사
◦
패키지 정렬? 배열?을 어떤 기준으로 하는 것이 명확할까요?
▪
특히, goods(공연), sequence(회차), 좌석(seat), 공연장(place) 가 너무 depth 가 깊지않게 구성하고 싶은데 service나 controller가 작성되지 않더라도 패키지 분리가 좋을까요? 아니면 place → seat , goods → sequence 이런식으로 하위로 넣어주는 것이 명확할까요
그냥 빼서 쓰자!
◦
엔티티와 request, response dto 에서 원시타입과 참조타입의 사용
▪
특정 필드에 대해서, 참조 타입 대신에 원시 타입을 사용해도 되는 부분?
▪
만약 쓴다면, dto 와 entity 의 각 타입을 맞춰줘야 합니까?
▪
만약 안 맞춰줘도 된다면, dto에서 참조 타입과 원시 타입 중 사용하기에 더 맞는 부분은 무엇일까요?
▪
jdbc api에서 쿼리문을 만들어줄때 sql dataType이 원시 타입으로으로 매핑해?
◦
경매 남은 시간에 관련하여 의견이 있는데, 어떻게 생각하시나요? **Good Idea**
1.
좌석 추가 시, 경매 등록(DB에)
2.
redis 에 key(경매 id), value(해당 경매에 대한 입찰가) 남은 시간 등록(현재 ~ 경매 종료될 때까지의 시간) TTL
3.
유저들이 좌석을 선택
4.
웹 소켓을 여는데, STOMP 방식(채팅방 처럼), 1번 좌석을 선택한 모든 유저들을 하나의 채팅방에 초대하는 형식
5.
여기서 redis에 저장된 남은 시간을 뿌려줌
6.
경매 종료 == redis 에 키가 expire됨
7.
키에 대해서 listener를 두고 계속 체크
8.
이제 키가 없어지면, 경매 종료를 호출
▪
궁금증
•
종료 체크 시 listener를 둔다.
•
이걸 어떤식으로 할 것인가?
•
답변
◦
redis KeyExpirationEventMessageListener
•
숙제: 멘토링 결과 다음 주까지 해올 일
◦
공통으로 진행해야 하는일
▪
서비스 로직구현 완료 및 테스트코드 작성으로 통한 로직 오류 잡기
◦
개인별 할일 - 정성호
▪
엔티티 리팩토링
▪
공연 서비스 로직 MVP 30% 로직구현
◦
개인별 할일 - 김진훈
▪
엔티티 리팩토링
▪
예매 서비스 로직 MVP 30% 로직구현
◦
개인별 할일 - 김민중
▪
엔티티 리팩토링
▪
경매 서비스 로직 MVP 30% 로직구현
◦
개인별 할일 - 김혜윤
▪
회원 서비스 로직 MVP 50% 로직구현
▪
토스 결재(포인트) 연동 설계
