Skip to content

Commit 227febd

Browse files
pable91pable91
authored
Merge pull request #2 from pable91/feature/round2/round2
Feature/round2/round2
2 parents c4c098a + 47f35e3 commit 227febd

6 files changed

Lines changed: 629 additions & 0 deletions

File tree

‎.claude/skills/requirements-analysis/SKILL.md‎

Lines changed: 81 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,81 @@
1+
---
2+
name: requirements-analysis
3+
description:
4+
제공된 요구사항을 분석하고, 개발자와의 질문/대답을 통해 애매한 요구사항을 명확히 하여 정리합니다.
5+
모든 정리가 끝나면, 다음을 Mermaid 문법으로 작성합니다.
6+
1. 시퀀스 다이어그램
7+
2. 클래스 다이어그램
8+
3. ERD
9+
요구사항이 제공되었을 때, 코드를 작성하기 전 이를 명확히 하는 데에 사용합니다.
10+
11+
---
12+
요구사항을 분석할 때 반드시 다음 흐름을 따른다.
13+
### 1️⃣ 요구사항을 그대로 믿지 말고, 문제 상황으로 다시 설명한다.
14+
- 요구사항 문장을 정리하는 데서 끝내지 않는다.
15+
- "무엇을 만들까?"가 아니라 "지금 어떤 문제가 있고, 그걸 왜 해결하려는가?" 로 재해석한다.
16+
- 다음 관점을 분리해서 정리한다:
17+
- 사용자 관점
18+
- 비즈니스 관점
19+
- 시스템 관점
20+
> 예시
21+
> "주문 실패 시 결제를 취소한다" → "결제 성공/실패와 주문 상태가 어긋나지 않도록 일관성을 유지하려는 문제"
22+
23+
### 2️⃣ 애매한 요구사항을 숨기지 말고 드러낸다
24+
- 추측하거나 알아서 결정하지 않는다.
25+
- 요구사항에서 결정되지 않은 부분을 명시적으로 나열한다.
26+
**다음 유형의 질문을 반드시 포함한다:**
27+
- 정책 질문: 기준 시점, 성공/실패 조건, 예외 처리 규칙
28+
- 경계 질문: 어디까지가 한 책임인가, 어디서 분리되는가
29+
- 확장 질문: 나중에 바뀔 가능성이 있는가
30+
31+
### 3️⃣ 요구사항 명확화를 위한 질문을 개발자 답변이 쉬운 형태로 제시한다
32+
- 질문은 우선순위를 가진다 (중요한 것부터).
33+
- 선택지가 있는 경우, 옵션 + 영향도를 함께 제시한다.
34+
> 형식 예시:
35+
- 선택지 A: 하나의 트랜잭션으로 처리 → 구현 단순, 확장성 낮음
36+
- 선택지 B: 단계별 분리 → 구조 복잡, 확장/보상 처리 유리
37+
38+
### 4️⃣ 합의된 내용을 바탕으로 개념 모델부터 잡는다
39+
- 바로 코드나 기술 얘기로 들어가지 않는다.
40+
- 먼저 다음을 정의한다:
41+
- 액터 (사용자, 외부 시스템)
42+
- 핵심 도메인
43+
- 보조/외부 시스템
44+
- 이 단계는 “구현”이 아니라 설계 사고 정렬이 목적이다.
45+
46+
### 5️⃣ 다이어그램은 항상 이유 → 다이어그램 → 해석 순서로 제시한다
47+
**다이어그램을 그리기 전에 반드시 설명한다**
48+
- 왜 이 다이어그램이 필요한지
49+
- 이 다이어그램으로 무엇을 검증하려는지
50+
51+
**다이어그램은 Mermaid 문법으로 작성한다**
52+
사용 기준:
53+
- **시퀀스 다이어그램**
54+
- 책임 분리
55+
- 호출 순서
56+
- 트랜잭션 경계 확인
57+
- **클래스 다이어그램**
58+
- 도메인 책임
59+
- 의존 방향
60+
- 응집도 확인
61+
- **ERD**
62+
- 영속성 구조
63+
- 관계의 주인
64+
- 정규화 여부
65+
66+
### 6️⃣ 다이어그램을 던지고 끝내지 말고 읽는 법을 짚어준다
67+
- "이 구조에서 특히 봐야 할 포인트"를 2~3줄로 설명한다.
68+
- 설계 의도가 드러나도록 해석을 붙인다.
69+
70+
### 7️⃣ 설계의 잠재 리스크를 반드시 언급한다
71+
- 현재 설계가 가질 수 있는 위험을 숨기지 않는다.
72+
- 트랜잭션 비대화
73+
- 도메인 간 결합도 증가
74+
- 정책 변경 시 영향 범위 확대
75+
- 해결책은 정답처럼 말하지 않고 선택지로 제시한다.
76+
77+
### 톤 & 스타일 가이드
78+
- 강의처럼 설명하지 말고 설계 리뷰 톤을 유지한다
79+
- 정답이라고 제시하기보다, 다른 선택지가 있다면 이를 제공하도록 한다.
80+
- 코드보다 의도, 책임, 경계를 더 중요하게 다룬다
81+
- 구현 전에 생각해야 할 것을 끌어내는 데 집중한다

‎CLAUDE.md‎

Lines changed: 120 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,120 @@
1+
# CLAUDE.md
2+
3+
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
4+
5+
## Build & Run Commands
6+
7+
```bash
8+
# 인프라 실행 (MySQL 3307, Redis 6379/6380, Kafka 19092, Kafka UI 9099)
9+
docker compose -f ./docker/infra-compose.yml up
10+
11+
# 모니터링 실행 (Prometheus 9090, Grafana 3000)
12+
docker compose -f ./docker/monitoring-compose.yml up
13+
14+
# 전체 빌드
15+
./gradlew build
16+
17+
# 특정 모듈 빌드
18+
./gradlew :apps:commerce-api:build
19+
20+
# 전체 테스트
21+
./gradlew test
22+
23+
# 특정 테스트 클래스 실행
24+
./gradlew :apps:commerce-api:test --tests ExampleV1ApiE2ETest
25+
26+
# 코드 커버리지 리포트
27+
./gradlew jacoco
28+
29+
# Swagger UI: http://localhost:8080/swagger-ui.html
30+
```
31+
32+
## Architecture
33+
34+
Java 21 / Spring Boot 3.4.4 멀티모듈 Gradle 프로젝트.
35+
36+
### Module Structure
37+
38+
- **apps/** — 실행 가능한 Spring Boot 애플리케이션 (BootJar)
39+
- `commerce-api` — REST API 서버 (Web, JPA, Redis, Swagger)
40+
- `commerce-batch` — 배치 처리 (web-application-type: none)
41+
- `commerce-streamer` — Kafka 컨슈머 스트리밍
42+
- **modules/** — 재사용 가능한 인프라 설정 (java-library, test-fixtures 제공)
43+
- `jpa` — JPA/Hibernate, QueryDSL, HikariCP, BaseEntity(soft delete, audit)
44+
- `redis` — Master-Replica 구성, Lettuce, 읽기/쓰기 분리
45+
- `kafka` — 배치 리스너(3000건), Manual ACK, JsonSerializer
46+
- **supports/** — 부가 기능 모듈
47+
- `jackson` — JSR310 직렬화 설정
48+
- `logging` — 프로파일별 logback (local: 텍스트, dev+: JSON + Slack)
49+
- `monitoring` — Prometheus/Micrometer, 관리 포트 8081
50+
51+
### Layered Architecture (commerce-api 기준)
52+
53+
```
54+
interfaces/api/ → Controller, DTO, ApiResponse, ApiControllerAdvice
55+
application/ → Facade (유스케이스 조합), Info (응답 DTO)
56+
domain/ → Model (JPA Entity), Repository (인터페이스), Service
57+
infrastructure/ → JpaRepository 구현체
58+
support/error/ → CoreException, ErrorType (에러 코드 enum)
59+
```
60+
61+
- Repository 패턴: domain에 인터페이스, infrastructure에 구현체
62+
- Facade 패턴: application 레이어에서 여러 도메인 서비스 조합
63+
- API 버전닝: `/api/v1/` 경로 기반
64+
- 글로벌 예외 처리: `ApiControllerAdvice`에서 `CoreException` → `ApiResponse` 변환
65+
66+
### BaseEntity (modules/jpa)
67+
68+
모든 엔티티의 부모 클래스. Auto-increment ID, `createdAt`/`updatedAt`/`deletedAt` 자동 관리, `delete()`/`restore()` 소프트 삭제 지원.
69+
70+
## Testing
71+
72+
- 테스트는 `spring.profiles.active=test`, timezone `Asia/Seoul`, `maxParallelForks=1`로 실행
73+
- **Testcontainers** 사용: MySQL, Redis, Kafka (각 모듈의 `testFixtures`에 설정 클래스 제공)
74+
- `DatabaseCleanUp` / `RedisCleanUp`: 테스트 후 데이터 정리 유틸리티
75+
- 테스트 종류: 단위(Model/DTO), 통합(Service+Repository), E2E(TestRestTemplate)
76+
- 개발 완료된 API 의 경우, `.http/**.http` 에 분류해 작성
77+
78+
## Configuration
79+
80+
- 프로파일: `local`, `test`, `dev`, `qa`, `prd`
81+
- 모듈별 설정 파일을 `spring.config.import`로 가져옴 (jpa.yml, redis.yml, kafka.yml, logging.yml, monitoring.yml)
82+
- 로컬 DB: `localhost:3307`, 계정 `application/application`, DB명 `loopers`
83+
- `.editorconfig`: 최대 줄 길이 130자 (테스트 파일은 제한 없음)
84+
85+
## Rule
86+
87+
### Code Writing
88+
89+
- 내가 코드 작성하라고 명령하기 전에 코드 작성 절대 금지
90+
- Example이 들어가는 파일들은 수정 금지 (참고만)
91+
92+
### Feedback
93+
94+
- 내 코드/아이디어에 무작정 동의하지 말고 객관적으로 피드백 ("이건 생각해봤어?" 식으로 유도)
95+
- 요구사항이 광범위하면 한 단계씩 점진적으로 진행
96+
97+
### Code Quality
98+
99+
- 테스트 코드 작성하기 좋은 구조로 설계
100+
- 테스트 코드가 필요한 곳이 있다면 알려줘
101+
- null-safety: Optional 적극 활용
102+
- 로그: println 금지, @Slf4j 사용
103+
104+
### TDD Workflow (Red > Green > Refactor)
105+
106+
#### 1. Red Phase
107+
108+
- 실패하는 테스트 먼저 작성
109+
- 요구사항을 만족하는 기능 테스트 케이스 작성
110+
111+
#### 2. Green Phase
112+
113+
- 테스트가 통과하는 최소한의 코드 작성
114+
- 오버엔지니어링 금지
115+
116+
#### 3. Refactor Phase
117+
118+
- 불필요한 코드 제거 및 품질 개선
119+
- 객체지향적 코드 작성, 성능 최적화
120+
- 모든 테스트 케이스가 통과해야 함

‎docs/01-requirements.md‎

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
### 유저 스토리 & 기능 흐름
2+
3+
- 모든 사용자는 회원가입할 수 있다
4+
1. 회원가입 버튼 클릭
5+
2. 규칙에 (형식에 맞지 않거나 이미 id가 있거나, 비밀번호에 id가 포함되면) 맞지 않으면 가입 불가
6+
3. 규칙을 지키면 가입 완료
7+
- 로그인한 유저는 자신의 정보를 조회할 수 있다
8+
1. 로그인한 사용자만 가능
9+
2. 정보 조회를 클릭하면 내 정보 조회 가능
10+
- 로그인한 유저는 자신의 비밀번호를 변경할 수 있다
11+
1. 로그인한 사용자만 가능
12+
2. 비밀번호 변경을 클릭한다
13+
3. 현재 비밀번호와 변경할 새 비밀번호를 기입한다
14+
4. 규칙(현재 비밀번호가 맞지 않거나, 새 비밀번호)에 맞지 않으면 변경 불가
15+
5. 규칙에 맞으면 비밀번호 변경 완료
16+
17+
### 브랜드,상품 스토리 & 기능 흐름
18+
19+
- 모든 유저는 브랜드 정보를 조회할 수 있다
20+
1. 브랜드 탭을 클릭한다
21+
2. 브랜드 목록이 조회된다
22+
3. 특정 브랜드 정보를 클릭하면 브랜드 상세 정보가 조회된다
23+
- 모든 유저는 상품 목록을 조회할 수 있다(페이징)
24+
1. 브랜드를 클릭한다
25+
2. 상품 목록이 조회된다
26+
- 모든 유저는 상품 정보를 조회할 수 있다
27+
1. 브랜드를 클릭한다
28+
2. 상품 목록이 조회된다
29+
3. 상품을 클릭한다
30+
4. 상품 정보가 조회된다
31+
32+
### 어드민 브랜드, 상품 스토리 & 기능 흐름
33+
34+
- 관리자는 등록된 브랜드 목록을 조회할 수 있다
35+
1. 브랜드 목록을 버튼을 클릭한다
36+
2. 존재한다면 목록을 조회한다
37+
3. 존재하지않으면 빈 목록을 조회한다
38+
- 관리자는 브랜드를 상세 조회를 할 수 있다
39+
1. 특정 브랜드 상세 조회 버튼을 클릭한다
40+
2. 브랜드 상세 조회한다
41+
- 관리자는 브랜드를 등록 할 수 있다
42+
1. 브랜드 등록 버튼을 클릭한다
43+
2. 브랜드의 정보를 입력한다
44+
3. 입력한 브랜드 정보가 유효하지 않으면(중복 등록, 잘못된 정보) 등록 불가하다
45+
4. 완료 버튼을 누르면 브랜드가 등록된다
46+
- 관리자는 브랜드의 정보를 수정할 수 있다
47+
1. 브랜드 수정 버튼을 클릭한다
48+
2. 정보를 수정하고 완료 버튼을 누른다
49+
- 관리자는 브랜드를 삭제 할 수 있다 (브랜드의 모든 상품삭제)
50+
1. 삭제할 브랜드를 선택한다
51+
2. 삭제한다
52+
- 관리자는 등록된 상품 목록을 조회할 수 있다(페이징)
53+
1. 특정 브랜드를 클릭한다
54+
2. 브랜드에 등록된 상품 목록을 페이징으로 조회한다
55+
3. 없으면 빈 목록을 보여준다
56+
- 관리자는 상품의 상세 조회할 수 있다
57+
1. 특정 브랜드를 클릭한다
58+
2. 브랜드의 등록된 상품 목록을 페이징으로 조회한다
59+
3. 특정 상품을 클릭하면 상품을 상세 조회한다
60+
- 관리자는 상품을 등록할 수 있다
61+
1. 특정 브랜드를 클릭한다
62+
2. 상품의 등록 버튼을 클릭한다
63+
3. 상품 정보를 입력한다
64+
4. 입력한 상품 정보가 유효하지 않으면(중복 등록, 잘못된 정보) 등록 불가하다
65+
5. 상품이 등록된다
66+
- 관리자는 상품 정보를 수정할 수 있다
67+
1. 특정 브랜드를 클릭한다
68+
2. 상품 목록 중 특정 상품을 클릭한다
69+
3. 상품 정보 수정 버튼을 클릭한다
70+
4. 수정할 정보를 입력한 뒤 완료 버튼을 클릭한다
71+
5. 입력한 상품 정보가 유효하지 않으면(중복 등록, 잘못된 정보) 수정 불가하다
72+
6. 상품이 수정된다
73+
- 관리자는 상품을 삭제할 수 있다
74+
1. 특정 브랜드를 클릭한다
75+
2. 상품 목록 중 특정 상품을 클릭한다
76+
3. 상품 정보 삭제 버튼을 클릭한다
77+
4. 상품이 삭제된다
78+
79+
### 좋아요 스토리 & 기능 흐름
80+
81+
- 로그인한 유저는 상품에 좋아요를 등록할 수 있다
82+
1. 로그인 사용자만 가능
83+
2. 좋아요 누르면 좋아요 존재 여부 판단
84+
3. 없으면 저장, 있으면 삭제
85+
4. 좋아요 수 반영
86+
- 로그인한 유저는 상품에 좋아요를 취소할 수 있다
87+
1. 로그인 사용자만 가능
88+
2. 좋아요 누르면 좋아요 존재 여부 판단
89+
3. 없으면 저장, 있으면 삭제
90+
4. 좋아요 수 반영
91+
- 로그인한 유저는 좋아요한 상품의 목록을 조회할 수 있다
92+
1. 로그인 사용자만 가능
93+
2. 좋아요한 상품의 목록 조회
94+
3. 있으면 전체 조회, 없으면 빈 값 조회
95+
96+
### 주문 스토리 & 기능 흐름
97+
98+
- 로그인한 유저는 상품을 주문할 수 있다
99+
1. 로그인 사용자만 가능
100+
2. 상품을 선택한다
101+
2. 선택한 상품 단건 또는 다건을 주문 버튼을 눌러 주문한다
102+
- 로그인한 유저는 주문 목록을 조회할 수 있다
103+
1. 로그인 사용자만 가능
104+
2. 주문 목록 조회
105+
3. 기간에 주문건이 존재하면 목록조회, 없으면 빈 값
106+
- 로그인한 유조는 단일 주문의 상세 조회할 수 있다
107+
1. 로그인 사용자만 가능
108+
2. 주문 목록에서 특정 주문의 상세를 조회할 수 있다
109+
110+
### 어드민 주문 스토리 & 기능 흐름
111+
112+
- 관리자는 주문 목록을 조회할 수 있다
113+
1. 관리자 사용자만 가능
114+
2. 주문 목록 조회, 없으면 빈 값
115+
- 관리자는 단일 주문을 상세 조회할 수 있다
116+
1. 관리자 사용자만 가능
117+
2. 주문 목록 조회
118+
3. 특정 주문을 클릭하면 상세 조회

0 commit comments

Comments
 (0)