서버구축 - 설계
이번 주차는 시나리오에서 요구하는 기능들이 동작하기 위한 설계를 하는 과정이었습니다. 시나리오의 분석 결과를 바탕으로 Sequence Diagram, Class Diagram, Entity Relationship Diagram(ERD), (+ Flow chart) 산출물을 작성하였습니다.
이를 통해 유지보수 및 확장이 가능한 코드, 테스트 가능한 코드, 견고하지만 유연한 서버를 설계할 수 있는 기본기를 학습했습니다.
E - commerce 서비스 요구사항 분석
Description 분석
- 상품 주문에 필요한 메뉴 정보들을 구성하고 조회가 가능해야 합니다.
- 주문과 관련된 로직이 주요 포인트이다.
- 모든 기능과 기획은 주문이 수월하게 진행되도록 하는 것을 목표한다.
- 주문이 이뤄지기 위한 다른 정보들을 정의해야한다.
- 사용자는 상품을 여러개 선택해 주문할 수 있고, 미리 충전한 잔액을 이용합니다.
- 상품 주문 시 다중 선택을 고려해야한다.
- 상품 목록 조회
- 주문 시 배열 요청
- 상품 주문 내역을 통해 판매량이 가장 높은 상품을 추천합니다.
- 주문 내역 기반으로 조회한다.
- 수량 또는 판매액의 상품을 정렬해야한다.
Requirements 분석
- 아래 5가지 API 를 구현합니다.
- 잔액 충전 / 조회 API
- 상품 조회 API
- 주문 / 결제 API
- 선착순 쿠폰 API
- 인기 판매 상품 조회 API
- 각 기능 및 제약사항에 대해 단위 테스트를 반드시 하나 이상 작성하도록 합니다.
- (심화) 재고 관리에 문제 없도록 구현합니다.
- Product(또는 ProductOption)에 stock 재고량에 대한 정의가 있어야 한다.
- 주문 시점, 혹은 결제 시점에서 재고가 차감되거나, 원복되는 로직이 있어야 한다.
- (심화) 동시성 이슈를 고려하여 구현합니다.
- 잔액의 충전 또는 사용이 순차적으로 처리되어야 한다.
- (심화) 다수의 인스턴스로 어플리케이션이 동작하더라도 기능에 문제가 없도록 작성하도록 합니다.
- 경쟁조건, 중복 처리, 외부 연동과 같은 상황을 염두해야한다.
- 단순 DB락 만으로는 부족하며, 분산락, 멱등성, 상태 전이 모델, 큐 기반 아키텍처 등으로 보완해야한다.
API Specs 분석
기본과제
1️⃣ 주요 잔액 충전 / 조회 API
- 결제에 사용될 금액을 충전하는 API 를 작성합니다.
- 사용자 식별자 및 충전할 금액을 받아 잔액을 충전합니다.
userId,amount값을 받아POST방식으로 충전
- 사용자 식별자를 통해 해당 사용자의 잔액을 조회합니다.
userId를 통해GET요청 시balance반환
2️⃣ 기본 상품 조회 API
- 상품 정보 ( ID, 이름, 가격, 잔여수량 ) 을 조회하는 API 를 작성합니다.
/products,/products/${productId}로GET요청 시 상품 또는 상품 배열 반환
- 조회시점의 상품별 잔여수량이 정확하면 좋습니다.
- 상품 또는 상품 옵션 별 재고 수량 포함
3️⃣ 주요 선착순 쿠폰 기능
- 선착순 쿠폰 발급 API 및 보유 쿠폰 목록 조회 API 를 작성합니다.
POST/coupons
- 사용자는 선착순으로 할인 쿠폰을 발급받을 수 있습니다.
- 발급된 수량과 남은 수량을 쿠폰 정책에 포함해야한다.
- 주문 시에 유효한 할인 쿠폰을 함께 제출하면, 전체 주문금액에 대해 할인 혜택을 부여받을 수 있습니다.
- 주문 시 유효하지 않은 쿠폰에 대한 예외처리
- 정률(또는 정액) 할인 금액에 대한 잔액 차감 전 결제액 차감
4️⃣ 주요 주문 / 결제 API
- 사용자 식별자와 (상품 ID, 수량) 목록을 입력받아 주문하고 결제를 수행하는 API 를 작성합니다.
userId와productId(oroptionCode),quantity를 배열로 받는POST요청을 구현한다.
- 결제는 기 충전된 잔액을 기반으로 수행하며 성공할 시 잔액을 차감해야 합니다.
- 상품 재고에 대한 예외 처리
- 잔액 부족에 대한 예외 처리
- 데이터 분석을 위해 결제 성공 시에 실시간으로 주문 정보를 데이터 플랫폼에 전송해야 합니다. ( 데이터 플랫폼이 어플리케이션
외부라는 가정만 지켜 작업해 주시면 됩니다 )- 외부로도 전송되어 데이터의 일관성이 훼손되지 않도록 유의해야한다.
- 전송 실패 시 재시도에 대한 상황도 고려해야한다.
- 외부 전송 실패가 주문 과정에 영향을 주지 않도록 해야한다.
- 고유한 정보를 바탕으로 멱등 처리가 되어야 한다.
데이터 플랫폼으로의 전송 기능은 Mock API, Fake Module 등 다양한 방법으로 접근해 봅니다.
5️⃣ 기본 상위 상품 조회 API
- 최근 3일간 가장 많이 팔린 상위 5개 상품 정보를 제공하는 API 를 작성합니다.
- 주문 기반으로 데이터를 조회하여 3일 간 상위 5개라는 조건에 맞는 상품을 반환한다.
- 다만, 추후 3일과 5개라는 조건에 대한 내용을 DB 로 고정해버리면 확장성이 떨어진다.
- 통계 기록용 테이블(1회 조회후 캐싱)을 고려한다.
- 통계 정보를 다루기 위한 기술적 고민을 충분히 해보도록 합니다.
- Client의 KPI가 어떤 것인 지 파악을 하고, 그에 맞는 통계를 제공하는 것이 필요하다.
- 통계를 주기적으로 생성하되, Order와 같은 테이블을 직접 참조하지 않고, 로그 테이블을 사용하는 것을 고려한다.
Sequence Diagram
- 시퀀스 다이어그램은 시스템 내 객체들 간의 상호작용을 시간 순서대로 시각화한 다이어그램입니다.
- 요청-응답 흐름, API 호출, 이벤트 처리 순서 등을 설계할 때 사용됩니다.
- 구성 요소: 주체(
Actor), 메시지(호출), 수명선(Lifeline), 응답
Class Diagram
UML에서 시스템의 구조를 시각화하는 데 사용되며,클래스 간의 관계,속성,메서드를 표현합니다.- 주로 도메인 모델링, 객체지향 설계, DB 스키마 설계 초안에 활용됩니다.
- 구성 요소:
클래스 이름,필드,메서드, 연관(association), 상속(generalization), 집합(aggregation), 포함(composition)관계등
ERD
- 데이터베이스 설계 시 엔티티(테이블) 간의 관계를 시각적으로 표현한 다이어그램입니다.
- 구성 요소:
Entity,Attribute,Relationship
Flow chart
Swagger API (OpenAPI)
Java(Spring)에서 REST API 명세를 자동 문서화하기 위한 도구입니다.@Operation,@Parameter,@Schema등을 이용해 API 설명, 파라미터, 응답 모델을 명시할 수 있습니다.Swagger UI를 통해 브라우저에서 API를 테스트를 제공하여, 팀원, FE개발자에게 공유할 수 있습니다.
KPT 회고
Keep
- 하루 2시간 이상은 프로젝트를 확인하고, 더 깔끔한 방향으로 개선해 나갔습니다.
- 커밋을 쪼개는 습관에서 PR도 쪼개는 습관으로 확장했습니다.
- 아직 squash는 제대로 해본적이 없어서 다음에는 쪼갠 PR의 커밋을 합쳐보도록 하겠습니다.
Problem
- IntelliJ 사용 2주차에 접어들어 아직 단축키는 하나도 모르지만, IDE 편의성으로 겨우겨우 버티는 중입니다.
- 회사에서 잠깐 수정할 때 VScode로도 똑같이 실행 시킬 수 있었어서, 순간 그냥 vsc 사용할까 하는 생각이 들었었습니다.
- 빠르게 숙달하는 방법이 있는 지 찾고 싶은데, 아직 과제를 해결하기에 급급한 것 같습니다.
- 업무를 Next.js, Remix.js, Typescript, PHP로만 하고 있다보니, Java와 Kotlin의 감각이 모두 날아간 것 같습니다.
- Prisma ORM을 활용한 ERD 문서화만 작업하다보니, 문서나 코드 Mermaid를 활용한 각종 다이어그램에 대해 무지한 부분이 있었습니다.
Try
- Swagger 처음 사용해봤는데, 왜 사용하는 지 알것 같은 편의성이 있었습니다.
- 서버를 띄우면 좋았겠지만, 문서화가 중점인 것으로 생각되어 정적으로 Swagger 문서를 제공하였습니다.
