[항해 플러스 백엔드 6기] 3주차 회고 - 콘서트 예약 시스템을 설계해보자..!

목차

 

 

이번주는 남은 7주간 진행할 프로젝트를 선정하고 설계하는 시간을 가졌다.

코치님께서는 설계이기 때문에 이번주는 쉬어가는 시간이라고 하셨지만 평소에 생각이 많아 설계가 오래 걸리는 나에게는 구현하는 것보다 오랜 시간을 투자한 한주였다.. 설계는 역시 어렵다 😢

 

📚 과제 발제

3주차의 발제는 아래와 같다.

 

시나리오를 선택할 수 있었다. 아래와 같이 세 가지 선택사항이 있었고 각각의 요구사항을 보고 고르면 됐었다.
콘서트 예약 서비스의 경우 대기열을 따로 구현을 해야하기 때문에 난이도가 가장 어렵다고 하셨다. 그래서 우리 조는 불나방처럼 다같이 콘서트 대기열 서비스에 도전하기로 했다..! 🔥🔥🔥🔥 화이팅 17조...!

• e-커머스 서비스
• 맛집 검색 서비스
• 콘서트 예약 서비스

더보기

 

STEP 05

• 시나리오 선정 및 프로젝트 Milestone 제출
• 시나리오 요구사항 별 분석 자료 제출
• 시퀀스 다이어그램, 플로우 차트 등
• 자료들을 리드미에 작성 후 PR 링크 제출

STEP 06

• ERD 설계 자료 제출
• API 명세 및 Mock API 작성
• 자료들을 리드미에 작성 후 PR링크 제출 ( 채택할 기본 패키지 구조, 기술 스택 등 )

 

 

🤔 과제를 진행하면서의 고민들 

시퀀스 다이어그램은 얼마나 디테일 해야하는가..?

부끄럽지만 실무에서 나는 시퀀스 다이어그램을 따로 그리지 않았다. 설계를 하긴 하지만 다이어그램을 그려서 문서화하지는 않았다..!
그래서 이번 설계 과제는 더 어렵게 느껴졌던 것 같다.

 

시퀀스 다이어그램의 정의는 아래와 같다.  

"특정 행동이 어떠한 순서로 어떤 객체와 어떻게 상호작용을 하는지 표현하는 행위 다이어그램"

 

멘토링 시간에 코치님께서는 코드 레벨에서 Service, DB 까지의 상호 작용이 아닌 도메인끼리의 상호 작용을 표현해보는 걸 추천해주셨다.. 더 어려웠다. 도메인 간의 상호작용을 표현한다..? 말로만 들었을 때는 잘 와닿지 않았다.

 

또 시퀀스 다이어그램을 작성할 때, 에러 표현을 하나하나 다 해주어야 하나? 라는 생각도 들었다.

예를 들어 콘서트 좌석을 예약하는 경우 아래와 같은 에러 사항이 나올 수 있다.

 

1. 대기열 토큰이 활성화 되지 않은 경우

2. 유저의 정보가 없는 경우

3. 콘서트 정보가 없는 경우

4. 콘서트 세션 정보가 없는 경우

5. 콘서트 좌석 정보가 없는 경우

6. 콘서트의 좌석이 예약 불가능한 상황인 경우

... 등

 

여기서 모든 사항이 시퀀스 다이어그램에 표현해야하나? 라는 생각이 들었고, 비즈니스 로직에서의 에러라고 생각하는 1, 7번에 대해서만 표현하기로 했다. 이것에 대한 피드백을 받았는 데 코치님께서도 비즈니스 에러라고 생각하는 경우에만 표현을 하신다고 하셨다.

=> 비즈니스 에러 라고 판단하는 자신만의 기준이 있으면 좋을 것 같다.

 

 

 

 

⭐️ 결과물 및 피드백

피드백

이번 주차를 진행한 부분에서 코드 리뷰 사항을 남겼었는데 코치님께서 피드백을 정성스럽게 남겨주셨다..!
POST 요청인 경우 리퀘스트 바디가 없도록 설계하는게 이상하지 않나? 라는 생각이 있었는데 없을 수도 있고 그게 표준이라 답변을 해주셔서 고민이 좀 해결된 것 같다..!

 

항해 하면서 평소에 갖고 있던 고민들을 많이 물어보고 양질의 답변을 주시고 해결해나가고 있어서 매우 만족스럽다!! 앞으로의 과제를 진행하면서 고민 사항들이 계속 나올텐데 벌써부터 기대가 된다ㅎㅎㅎ 😃

 

이번주차는 우수로 뽑혔다!! ㅎㅎ (자랑)
고민하는데 시간을 많이 쏟은 만큼 더욱 뿌듯하다!! 😆 앞으로도 지금처럼 열심히 해야지..! (더 열심히는 힘들어서 못해... 지금처럼만...!)

 

 

결과물

• https://github.com/rueun/hhplus-concert-reservation

GitHub - rueun/hhplus-concert-reservation: 항해 플러스 과제 - 콘서트 예약 서비스

 

 

 

🌸 이번 주 느낀 점  & 배운 것

• 개발 전 문서화 과정은 굉장히 중요하다!!!!
  • 개발자 뿐만 아니라 모든 이해관계자들과 소통을 유의미 있고 효율적으로 하기 위해서는 꼭 필요한 과정이라 느꼈다.
  • 앞으로 현업에서 적용해서 팀 내부적으로 더 나아가 전사적으로 적용을 해보면 좋지 않을까 생각이 든다. 그렇게 되기 위해서는 내가 잘해서 좋은 평가를 받아야겠지만...!
• created_at, updated_at 은 기본적으로 넣어주기
• DB 에 enum 을 사용하는 것보다는 varchar 사용하기
  • enum 은 특정 DB 에 종속적이며, 변경 사항이 있을 때마다 업데이트를 쳐줘야 하는 등의 작업을 해줘야 한다.
• pk 는 bigint 로 표현하자.
• 데이터베이스에서는 스네이크 케이스 표기법이 기본 권장된다.
• GET 요청이더라도, 다양한 프로퍼티를 통해 요청 질의해야 한다면 이를 명시하고 의도적으로 POST 로 작성할 때도 많다. ( 예를 들면 뭐를 조회하는데, 쿼리에 필요한 다양한 요구사항을 수용하는 경우 )
• 특정 동작을 트리깅하거나, 별도의 리소스가 필요하지 않은 경우 POST 도 RequestBody 를 포함하지 않아도 된다. ( 이건 표준 )

 

 

 

 

---

할인 코드 입력하시고 20만원 혜택 받으세요!

항플 추천인 코드 :  KjKuTu