[항해플러스 7기 백엔드] 3주차 회고 - 서버 구축하기 (설계부터~)

3주차부터 5주차까지는 이전 과제보다는 긴 호흡으로 서버를 구축하는 과제를 진행한다.

 

3주차는 설계 단계로 프로젝트의 시작인 마일스톤 작성하기, 도메인 간의 흐름을 시간순으로 나타내는 시퀀스 다이어그램 작성하기, ERD 설계하기, API 명세서와 MockAPI 작성하기를 진행했다.

코딩이 없어서 조금 편하겠구나 라고 생각했는데 그렇지 않았다...

설계한 내용을 다음주에 코딩으로 구현한다고 생각을 하니 이걸 어떻게 코드로 구현할지를 머릿속으로 구상하면서 설계를 진행해야했고, 많은 시간을 나의 머릿속의 생각들과,,, 싸워야,,, 했다,,,(이렇게 깊은 생각을 해본 게 얼마만이던가,,,ㅜ)

 

마일스톤

 

마일스톤은 Github에 Project를 이용하여 작성하였다. 이번 과제를 진행하면서 새롭게 알게 된 깃허브의 기능이었는데 UI도 깔끔하고 잘 활용하면 프로젝트 진행에 도움이 될 것 같았다. 항해를 진행하면서 느낀 점인데 이런 툴을 알고, 그것을 잘 활용하는 것도 업무 효율을 높이는 데 굉장한 도움이 된다.

 

시퀀스 다이어그램

주문/결제 시퀀스 다이어그램

선택한 시나리오는 이커머스 시스템의 상품주문 서비스였다. 시퀀스 다이어그램은 Mermaid(https://www.mermaidchart.com/)를 사용하여 그렸다.

각 기능에 대한 시퀀스 다이어그램을 모두 그렸는데, 그 중 가장 고민이 필요했던 기능은 주문/결제 로직이었다.

어느 단계에서 재고 확인/차감을 해야하는지, 어느 단계에서 잔액 확인/차감을 해야하는지에 대한 고민이 있었다.

처음에는 결제 단계에서 재고와 잔액의 차감을 처리해야하지 않을까라고 생각했고, 재고에 대한 확인은 주문/결제 단계에서 모두 이뤄져야 한다고 생각했다. 멘토링 시간에 코치님께 질문을 통해 확인하였고, 이커머스 분야에 오래 재직하고 계신 코치님께서 명료하게 설명을 해주셨다. (재고는 주문 도메인에서 관리, 잔액은 결제 단계에서 관리! 실패 시 취소 로직 필요!) 역시 모를 땐 물어보는 게 최고,,,

 

ERD

이번 주차의 ERD는 Mermaid 툴을 사용해서 그려보았다. 테이블 간의 관계를 코드 한 줄로 표현할 수 있어서 편리하다고 느껴졌다.

 

처음에는 그리 복잡하지 않았던 ERD가 재고 분리, 히스토리 테이블 생성 과정을 거치면서 복잡한 형태를 가지게 되었다,,

포인트도 별도의 테이블로 분리할까 고민했지만 지금 User 테이블이 가지고 있는 데이터가 이름, 잔액(포인트) 뿐이어서 포인트까지 분리할 필요는 없다고 판단했다.

 

API 명세서, MockAPI

원래는 명세서를 먼저 작성한 후 명세서를 바탕으로 MockAPI를 만들고자 하였으나,, 직접 코드를 작성해봐야 감이 올 것 같아 MockAPI 작성을 먼저 진행하였다. 

먼저 2주차 프로젝트를 참고하며 아키텍처 구조를 잡고, interfaces/ 패키지 아래 컨트롤러 클래스와 request, response DTO 클래스를 만들어가며 MockAPI 를 작성하였다. 

 

실제 현업이었다면 협력 부서에서 이 MockAPI를 사용해 작업을 한다고 생각하니 이후 수정사항이 최대한 발생하지 않도록,, 고려하면서 신중하게 작성했던 것 같다... 코드로 구현하며 수정이 발생하지 않기를,,,🙏🏻

 

명세서는 md 파일로 작성했다. 작성된 MockAPI를 Postman으로 테스트해보면서 문서화를 진행하였다. 

 

너무 감사하게도 이번 주차 과제도 따봉을 받았다,,

내가 느끼는 나는 너무 부족한데,, 잘하고 있는걸까 하는 생각을 하게된 것 같다,,

항해,, 좋은 것만 주셔서 정말 감사합니다,,🫶🏻

---

4주차에 구현을 진행하면서 지금의 설계가 수정될 수도 있겠지만... 최대한 수정이 발생하지 않기를 바라면서,,,

4주차도 화이팅,,,!🫶🏻