[항해플러스 백엔드] 4 , 5주차 회고

🌿 4 , 5주차 완료 !

 

4 , 5 주차는 E-commerce , 콘서트 도메인 중 선택하여 API 서버를 구축하는 주차이다. 내가 항해에서 가장

기대했던 주차이다ㅎㅎ 그 이유는 나는 확실히 이론공부도 좋지만 코드를 작성해보면서 직접 내 손으로 무언가를

만들어본다는 게 나에게 큰 흥미를 준다. 내 선택은 E-commerce이다.

항상 E-commerce도메인에서의 실무를 한 번쯤은 해보고 싶기도 하고 주문 , 결제 , 상품 , 사용자 , 관리자와

같은 기능들이 다른 도메인에서도 공통으로 사용되는 부분들이 많다고 생각해서 선택하게 되었다.

아 그리고 정말 열심히 했고 자신있던 주차인데 fail 하나..를 받은 게 개인적인 목표가 깨지다보니ㅠㅠ 아쉬운 마음이 있는 주차다. 
하지만 항해에서 얻어가는 것이 all pass가 중요한 게 아니라 내가 얼마나 성장하냐이기 때문에 이런 경험에서도
어떤 것을 배울 수 있을까라는 자세로 마음을 다 잡는 주차였습니다. fail받은 이유는 밑에 "아쉬웠고 개선하자" 목차에서 
회고 개념으로 기록해 놓을 것입니다.

🌿 만족 하고 유지  하자 !

이번 API 서버 구축을 통해 설계부터 구현까지 각 순서마다 중요한 부분과 어떤 방향으로 해나가야 할 지 어느정도 감을 잡을 수 있었다.

1. 요구사항 분석 
2. 설계 (ERD , 시퀀스 다이어그램 등)
3. 패키지 구조 잡기
4. 구현
   1. 테스트 코드 작성
   2. 구현 코드 작성
   3. 리팩토링

 1. 요구사항 분석

요구사항은 날카롭고 뾰족하게 깍아내자!!!(기획팀도 개발팀도 완벽하지 않다!)

항해 교육 이전에는 요구사항을 보고 성공 하는 상황만 생각하고 코드 작성을 진행 해왔는데 이번 과제에서는

요구사항별 실패케이스를 세분화하고 성공 케이스를 정리하는 순서로 진행했습니다.

(실패 케이스의 세분화는 입력값에 대해 실패 , 정책에 의한 실패와 같이 정리)

위와 같은 방식으로 진행해보니 분석단계에서의 시간소모가 늘어나지만 설계에서는 자세한 엔티티의 연관관계 ,

필드들에 대한 정리가 수월해졌습니다. 또한, 테스트 코드 작성시에도 테스트 시나리오를 요구사항 분석대로

정하면 되어서 전체적인 개발 속도가 크게 올라갔다는 느낌을 받았습니다.

 

 2.  설계

 

ERD 작성에서는 Entity의 연관관계에 대해서 고민을 하며 진행했습니다. BaseEntity 이용하여 생성 , 수정 시간 등의

공통 필드를 분리 했습니다. 요구사항 분석에 따라 큰 형태의 테이블의 필드를 정하고 추후 개발을 진행하며 수정하는 방식으로 진행했습니다.

 

시퀀스 다이어그램을 작성하며 기능마다 어떠한 순서로 비즈니스 로직이 진행되는 지 파악하는 데 큰 도움이 되었습니다.

이번에는 각 layer별로 구분을 해서 작성하였지만 다이어그램을 보는 사람에 따라 변경이 필요하다고 생각이 들었습니다.

 

 2 - 2. 설계 (패키지 구조)

 

• 주로 계층형 아키텍처를 기반으로 설계 해왔는데 이번 과제에서는 항해에서 배운 클린 + layer 아키텍처로 진행 했습니다. 이 아키텍처는 데이터 계층 및 API 계층이 비즈니스 로직(도메인)을 의존하여 도메인 중심적이며 DIP , OCP를 만족하는 계층 아키텍처입니다.
• 패키지 구조는 도메인 중심 구조로 구성하였습니다.
  • 가독성과 유지보수 쉬움
  • 도메인 모델에 집중하는 클린 + layer 아키텍처에 적합
  • 프로젝트의 규모가 커질수록 효율적.

 3. 구현

1. 테스트 코드 작성
2. 구현 코드 작성
3. 리팩토링

• 위와 같은 순서로 개발을 진행해보니 처음에는 의미없이 개발시간이 늘어나는 게 아닐까? 라는 걱정을 했었는데
  일정한 반복 , 숙달에 의해 어느순간부터는 시간적으로 테스트코드 없이 개발하는 방법과 크게 차이를 느끼지 못했습니다.
  그리고 무엇보다 현재 저의 개발 진행사항 작성된 테스트코드들을 보며 파악하기 훨씬 수월하게 느껴졌고 작성한 코드의
  잘못된 부분들을 잡아내기가 좋았습니다. 또한, 테스트 코드의 순서를 실패케이스 → 성공 케이스로 작성하다보니 해당
  케이스 별로 구현 코드 작성이 세분화되서 진행되므로 기능을 구현하는데도 코드 수정에 쓰는 시간을 많이 줄여준다고 느껴졌습니다.

🌿 아쉬웠고 개선하자 !  

 

이번 과제에서 Facade 패턴을 활용하여 주문과 결제 API를 하나의 유즈케이스로 묶고 , 이를 사용자의 입맛대로 제공하는 방식으로 설계하고 구현했습니다. 이 과정에서, 유즈케이스의 추가나 변경에 따라 여러 서비스 로직을 자유롭게 조합하여 활용할 수 있음을 깨달았습니다. 이를 통해 “유지보수성과 재사용성을 크게 향상시킬 수 있겠구나” 라는 생각을 하게 되었습니다. 이 과정에서 트랜잭션 설정에 대해 깊이 고민하고 신중하게 결정해야 합니다.

그리고, 위 과정에서 주문이 완료되면 재고가 차감되고 결제가 실패하게 되면 주문까지 취소되는 것이 아닌 주문의 결제상태를 결제대기로 변경하여 결제 과정에서 어떠한 오류로 실패했다고 사용자가 주문까지 다시한다는 건 서비스 입장에서 사용자의 불편함을 초래한다고 생각하여 결제와 주문의 트랜잭션을 분리했습니다.

하지만 이번 주차를 평가해주신 코치님의 생각은 결제가 취소되었는데 재고가 차감되지 않으면 재고관리가 잘 안된다고 생각하신다는 피드백을 주셨습니다. 이 부분에 대해선 추후에 소통을 통해 저의 의도가 코드단에 좀 더 명확하게 나타났다면 틀린 것이 아닌 다른 방법이라고 생각하여 fail을 주지 않았을 것이다라고 하셨다! 물론 이번 주차 결과를 변경할 수 없어 좀 아쉽지만 그래도 요구사항 분석은 정말 각자 의견이 다르고 생각이 다를 수 있기 때문에 실무에서는 설계과정에서부터 소통을 중요시 생각해야겠다고 느꼈습니다. 

 

🌿 마무리

 

4 , 5 주차는 프로젝트 설계부터 구현까지 진행하면서 재밌는 주차였고 TDD를 적용해보는 것이 처음이였는데

물론 아직 미숙하다 보니 개발 시간이 더 소모되긴 했지만 확실히 구현 부분에서 놓치는 부분이 훨씬 적어진다는 것을

느꼈고 실패 케이스부터 성공 케이스까지 테스트를 진행하다 보니 코드의 빈틈을 수월하게 찾고 해결할 수 있었습니다!

앞으로도 TDD 에 대해 깊이 학습해보고 꾸준히 적용해보아야겠다는 생각을 했습니다.