Skip to content

Commit 02c10f1

Browse files
rnqhstmdrnqhstmd
authored
Merge pull request #46 from rnqhstmd/main
[volume-2] 이커머스 설계 문서 작성
2 parents 040c860 + 25e3e7c commit 02c10f1

6 files changed

Lines changed: 508 additions & 0 deletions

File tree

‎.github/workflows/main.yml‎

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
name: PR Agent
2+
on:
3+
pull_request:
4+
types: [opened, synchronize]
5+
jobs:
6+
pr_agent_job:
7+
runs-on: ubuntu-latest
8+
steps:
9+
- name: PR Agent action step
10+
uses: Codium-ai/pr-agent@main
11+
env:
12+
OPENAI_KEY: ${{ secrets.OPENAI_KEY }}
13+
GITHUB_TOKEN: ${{ secrets.G_TOKEN }}

‎docs/img/erd.png‎

130 KB
Loading

‎docs/week2/01-requirements.md‎

Lines changed: 190 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,190 @@
1+
# 요구사항 명세
2+
3+
## 1. 유저 ↔ 브랜드 & 상품 (Brands & Products)
4+
5+
### 1-1. 👤 시나리오 (사용자 관점)
6+
7+
```
8+
사용자는 브랜드 정보를 확인하고, 다양한 정렬 기준으로 상품 목록을 조회할 수 있다.
9+
또한 특정 상품의 상세 정보를 확인할 수 있다.
10+
```
11+
12+
### 1-2. ⚙️ 기능 명세 (시스템 관점)
13+
14+
### 🔺 목적 : 사용자는 브랜드 정보를 확인하고, 브랜드별 상품을 다양한 기준으로 정렬하여 조회할 수 있어야 한다. 또한 상품 상세 정보를 조회할 수 있어야 한다.
15+
16+
### 🔺 주체 : 모든 사용자 (**또는 비로그인 사용자**)
17+
18+
### 🔺 주요 시나리오 :
19+
20+
```
21+
1. 사용자가 특정 브랜드 정보를 조회한다.
22+
2. 사용자가 상품 목록을 조회하며, 브랜드 필터와 정렬기준을 선택한다.
23+
3. 시스템은 요청한 정렬 기준에 따라 상품 목록을 정렬하고, 페이징된 결과를 반환한다.
24+
4. 각 상품에는 좋아요 수가 포함된다.
25+
5. 사용자가 로그인한 상태라면 각 상품에 대한 사용자의 좋아요 여부를 함께 조회하여 응답에 포함한다.
26+
6. 사용자가 특정 상품의 상세 정보를 요청하면, 시스템은 상품 정보와 좋아요 수를 반환한다.
27+
28+
```
29+
30+
### 🔺 시스템 동작 (낙관적) :
31+
32+
```
33+
1. 브랜드 조회:
34+
1-1. brandId 유효성 확인
35+
1-2. Brand 엔티티 조회
36+
1-3. 브랜드 정보 반환 (id, name, description 등)
37+
38+
2. 상품 목록 조회:
39+
2-1. 쿼리 파라미터 검증 (brandId, sort, page, size)
40+
2-2. Pageable 객체 생성 및 정렬 조건 적용
41+
- latest: createdAt desc (기본값)
42+
- price_asc: price asc
43+
- likes_desc: likeCount desc
44+
2-3. brandId가 있는 경우 해당 브랜드의 상품만 필터링
45+
2-4. 상품 목록 조회 및 각 상품의 좋아요 수 포함
46+
2-5. X-USER-ID 헤더가 있는 경우:
47+
- 해당 사용자의 좋아요 여부 조회 (IN 쿼리 또는 JOIN)
48+
- 각 상품에 isLiked 필드 추가
49+
2-6. 페이징 정보와 함께 상품 목록 반환
50+
51+
3. 상품 상세 조회:
52+
3-1. productId 유효성 확인
53+
3-2. Product 엔티티 조회 (Brand 정보 함께 조회)
54+
3-3. 상품의 좋아요 수 조회
55+
3-4. X-USER-ID 헤더가 있는 경우 해당 사용자의 좋아요 여부 조회
56+
3-5. 상품 상세 정보 반환 (상품 정보, 브랜드 정보, 좋아요 수, 좋아요 여부)
57+
```
58+
59+
### 🔺 예외 처리 (비관적) :
60+
61+
```
62+
1. 존재하지 않는 브랜드, 상품 ID 요청 시 -> 404
63+
2. 잘못된 형식의 브랜드/상품 ID (문자열, 음수 등) -> 400
64+
3. 잘못된 정렬 조건 (지원하지 않는 정렬 필드) -> 400 또는 기본 정렬(latest) 적용
65+
4. 잘못된 페이지 정보 (음수 페이지, 음수 사이즈, 페이지 사이즈 최대값 초과) -> 400 또는 기본값(최대값)으로 조정
66+
```
67+
68+
### 🔺 체크리스트 :
69+
70+
```
71+
1. 정렬 기준에 따라 응답 순서가 올바르게 정렬되는가?
72+
2. 좋아요 수가 상품 목록/상세에 정확히 포함되는가?
73+
3. 로그인 상태일 경우, 좋아요 여부가 함께 반환되는가?
74+
4. 비로그인 상태에서도 상품 목록/상세 조회가 가능한가?
75+
5. 페이징 정보(페이지 번호, 페이지 크기, 전체 페이지 수, 전체 요소 수)가 정확히 적용되는가?
76+
6. 브랜드 필터가 정확히 동작하는가?
77+
7. 잘못된 정렬 필드에 대한 기본 정렬이 적용되는가?
78+
```
79+
80+
## 2. 좋아요 (Likes)
81+
82+
### 2-1. 👤 시나리오 (사용자 관점)
83+
84+
```
85+
사용자는 상품에 좋아요를 등록하거나, 이미 등록된 좋아요를 취소할 수 있다.
86+
또한, 자신이 좋아요를 누른 상품 목록을 확인할 수 있다.
87+
```
88+
89+
### 2-2. ⚙️ 기능 명세 (시스템 관점)
90+
91+
### 🔺 목적 : **사용자는 상품에 좋아요를 등록하거나 취소할 수 있어야 하며, 내가 좋아요한 상품 목록을 조회할 수 있어야 한다.**
92+
93+
### 🔺 주체 : 로그인한 사용자
94+
95+
### 🔺 주요 시나리오 :
96+
97+
```
98+
1. 사용자는 상품에 좋아요를 등록하거나 취소할 수 있다.
99+
2. 시스템은 요청에 따라 좋아요 상태를 변경하고, 상품의 좋아요 수를 반영한다.
100+
3. 사용자는 본인이 좋아요한 상품 목록을 조회할 수 있다.
101+
```
102+
103+
### 🔺 시스템 동작 (낙관적) :
104+
105+
```
106+
1. 사용자 식별 및 인증
107+
2. productId 유효성 확인 및 Product 엔티티 존재 여부 확인
108+
3. 해당 사용자(userId)와 상품(productId)에 대한 Like 엔티티 존재 여부 조회
109+
4. 좋아요 등록 -> 좋아요가 없는 경우:
110+
4-1. Like 엔티티 생성
111+
4-2. Like 저장
112+
5. 좋아요 취소 ->좋아요가 있는 경우:
113+
5-1. Like 엔티티 삭제
114+
```
115+
116+
### 🔺 예외 처리 (비관적) :
117+
118+
```
119+
1. X-USER-ID 헤더 없음 (비로그인 사용자) -> 401
120+
2. 존재하지 않는 productId 요청 시 -> 404
121+
3. 잘못된 형식의 productId -> 400
122+
```
123+
124+
### 🔺 체크리스트 :
125+
126+
```
127+
1. 동일 사용자가 같은 상품에 여러 번 좋아요 요청 시 멱등하게 동작하는가?
128+
2. 좋아요 등록/취소 시 상품의 좋아요 수가 정확히 증감되는가?
129+
3. 비로그인 시도는 적절히 차단되는가?
130+
4. 존재하지 않는 상품에 좋아요 시도 시 적절히 처리되는가?
131+
5. 좋아요 수가 음수가 되지 않도록 방어 로직이 있는가?
132+
```
133+
134+
---
135+
136+
## 3. 주문 & 결제 (Orders)
137+
138+
### 3-1. 👤 시나리오 (사용자 관점)
139+
140+
```
141+
사용자는 상품을 선택하여 주문 결제를 진행할 수 있다.
142+
주문 시 포인트로 결제하며, 주문이 완료되면 주문 내역과 상세 정보를 확인할 수 있다.
143+
```
144+
145+
### 3-2. ⚙️ 기능 명세 (시스템 관점)
146+
147+
### 🔺 목적 : 사용자는 상품을 주문하고 포인트로 결제할 수 있어야 하며, 주문 후 본인의 주문 내역과 상세 정보를 확인할 수 있어야 한다.
148+
149+
### 🔺 주체 : 로그인한 사용자
150+
151+
### 🔺 주요 시나리오 :
152+
153+
```
154+
1. 사용자가 구매할 상품과 수량을 정해 주문을 요청한다.
155+
2. 시스템은 상품 재고 및 사용자 포인트를 확인하고 주문 가능 여부를 판단한다.
156+
3. 주문 정보와 결제를 처리한 뒤 응답을 반환한다.
157+
```
158+
159+
### 🔺 시스템 동작 (낙관적) :
160+
161+
```
162+
1. X-USER-ID 헤더로 사용자 식별 및 인증
163+
2. 상품의 존재 여부 확인
164+
3. 상품의 재고 확인
165+
4. 사용자 포인트 확인
166+
5. 포인트 잔액이 충분한지 확인
167+
6. 상품의 재고, 포인트 차감
168+
7. 주문 정보 생성
169+
8. 주문 정보를 외부 시스템으로 전송
170+
9. 주문, 구매 상품 내역, 결제 금액 등 포함하여 반환
171+
```
172+
173+
### 🔺 예외 처리 (비관적) :
174+
175+
```
176+
1. 로그인 하지 않은 사용자 -> 401
177+
2. 존재하지 않는 상품 ID 요청 시 -> 404
178+
3. 잘못된 형식의 주문 항목 -> 400
179+
4. 상품 재고 부족 -> 409
180+
5. 포인트 부족 -> 409
181+
```
182+
183+
### 🔺 체크리스트 :
184+
185+
```
186+
1. 주문 시, 재고/포인트 차감이 모두 트랜잭션 내에서 처리 되는지?
187+
2. 주문 실패 시, 모든 재고와 포인트는 롤백되는지?
188+
3. 동일한 요청을 여러 번 보내도 중복 주문이 되지 않는지?
189+
4. 응답에는 주문, 결제 ID와 구매 상품 내역, 총 결제 금액 등이 포함되어 있는지?
190+
```

0 commit comments

Comments
 (0)