06.15 이벤트 스토밍 이후 멘토님 피드백
- 이메일 추가하면 좋다.
- could와 should 정리하자
- 단순한 조회 필터링과 기능 추가의 우선순위 변경
- 유비쿼터스 얘기
- 회원 관련 용어의 단순화
- Accomodation → Room 더 간결한 용어 사용
06.20
- 주석을 많이 작성하자
- 내가 1년뒤 이 코드를 보아도 이해할 수 있게
- 도메인을 전혀 모르는 사람이 보아도 이해할 수 있게
- 특히나 도메인 코드에 많은 주석이 들어가는 것은 좋다!
06.20
- flyway 활용 추천
6.24
웹모델에서 엔티티 변환 x. 파라미터를 서비스로 넘겨줘서 그 안에서 엔티티 생성하는 식으로
- 테이블 별로 sql 따로 만들기 ( flyway로 db 버전관리)
- create → validate
도메인에 기능을 코멘트를 같이 잘 쓰기. 기능들에 대해명백하지 않은 내용들을 주석으로 달 것명백한 내용들은 주석으로 달지 않아도 됨 이런 식으로 링크 달 수 있음 /** * @see 어쩌고 **/
- Element collection — Role
Role 클래스 안에 역할 별로 어떤 기능을 하는지를 작성하는 코멘트를
member.isHost() ? 객체 안에 들어가서 헤집는것 보다, member.getRole.equals(Role.GUEST)
OneToMany(mappedBy )
- Review가 달렸는데 room의 상태가 바뀌어야 할까. reviewCount 같은 것은 캐쉬로 처리해도 좋을텐데
여행 도메인에 가격기준은 원화(코멘트로 남기기)
예약 버튼 누름 -> 예기약 완료 대 -> 체크아웃 두개로 해서 uq_key 걸음 + 대기 QUEUE에 넣었다가 순서대로 하나씩 처리 (시간 오버랩이 되었는가?) -> 예약 완료 -> 호스트가 수락 (시간 오버랩 되어있는게 있는지 알려주기)
- 동시성 문제
- Optimistic lock -> Version을 이용, select for update로 쿼리 락 걸던가
- Pessimistic lock -> db에 lock을 걸어두고 있는 것
- 예약 버튼 누름 -> 예약 완료 대기 -> queue 쌓고 순서대로 처리하면서 오버부킹되었는지 확인 -> 예약 완료
- 예약 버튼 누름 -> 예약 완료 대기 -> 호스트가 수락 -> 예약 완료 (시간 오버랩 되어 있는게 있는지 알려주기)
- 여행 등록 시
- Trip으로만 유지하고 가능은 함
totalPrice
- PasswordEncoder라는 시큐리티의 정보를 도메인에서 너무 알고있다. PasswordEncryptor라는 인터페이스를 이용하고 구현은 다른 패키지로 빼서 거기서 SpringSecurity의 의존성을
- RoomImage → S3로
- 예약 검증하는 플로우
오버랩된 시간이 있는지 확인하는 플로우 1. RESERVED, TRAVELLING 상태인 Room의 Trip 들을 모두 가져온다 2. checkin, checkout 사이의 날짜들을 list 형태로 가지고 있는다. 3. 현재 예약의 checkin, checkout 과 겹치는 날짜가 있는지 검사한다. -> stream().anyMatch() 이런거 활용하면 될거같음 4. 하나라도 있으면, checkArguments 터지면 될듯 여행하려는 룸하나 조회 1. RESERVED, TRAVELLING 상태인 Room의 Trip 들을 모두 가져온다 2. checkin, checkout 사이의 날짜들을 list 형태로 merge 해서 가지고 있는다 3. list를 같이 뿌려줘서 화면에서 예약된 시간은 스트라이크 처리 할 수 있도록 내려준다.
- A
ddress 내부 String address → description, postcode, road Address…
ofReserved 가 필요없다….
테스트에 TripStatus 변경테스트 → Parameterize…
6.25
- application.yaml에 값들 환경변수로 빼서 돌리기
- 커밋 훅으로 reformat code, optimize import. 적용하기