[2주차] 설계 문서 제출 - 최지호 #24
Conversation
Walkthrough제품, 좋아요, 주문 기능을 위한 종합 설계 문서 모음이 추가되었습니다. 유비쿼터스 언어, 요구사항, 시퀀스 다이어그램, 클래스 다이어그램, ERD를 포함한 5개의 설계 문서가 Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.docs/design/04-erd.md (1)
206-222: Point 동시성 제어 방안 명시 필요points 테이블의 동시성 제어 필요성이 주석으로 표시되어 있습니다(라인 218). 다음과 같이 보다 구체적인 구현 가이드를 추가하는 것을 권장합니다:
**비고:** - 동시성 제어 필요 (비관적 락) - 한 사용자당 하나의 포인트 레코드 + - 구현 방식: JPA @Lock(LockModeType.PESSIMISTIC_WRITE) + - 또는 SELECT ... FOR UPDATE 쿼리 사용이렇게 명시하면 향후 구현 시 동시성 전략이 더욱 명확해집니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
.docs/design/00-ubiquitous-language.md(1 hunks).docs/design/01-requirements.md(1 hunks).docs/design/02-sequence-diagrams.md(1 hunks).docs/design/03-class-diagram.md(1 hunks).docs/design/04-erd.md(1 hunks)
🔇 Additional comments (16)
.docs/design/00-ubiquitous-language.md (1)
1-12: 설계 문서의 기초로 명확하게 정의됨유비쿼터스 언어가 간결하게 정리되어 있으며, 후속 설계 문서들(요구사항, 클래스 다이어그램, ERD)과 일관되게 사용되고 있습니다. 각 용어에 대한 설명도 충분합니다.
.docs/design/01-requirements.md (1)
1-96: 요구사항이 체계적으로 구조화됨Main Flow, Alternate Flow, Exception Flow로 명확하게 구분되어 있으며, HTTP 메서드, 에러 코드, 멱등성 요구사항이 명시되어 있습니다. 외부 시스템 연동 시 트랜잭션 롤백 전략(라인 93)과 동시성 제어 필요성(라인 78-79)도 적절하게 문서화되어 있습니다.
.docs/design/02-sequence-diagrams.md (4)
1-41: 계층 구조와 흐름이 명확함첫 번째 시퀀스 다이어그램이 Controller → Facade → Service → Repository 계층을 잘 보여주고 있으며, 요청 검증(X-USER-ID 헤더, 정렬 옵션, 페이지 파라미터)과 비정규화된 likes_count 조회도 명시되어 있습니다.
50-83: 내 좋아요 목록 조회 흐름이 적절함Like 엔티티에서 상품 정보, 브랜드명, 등록 시간을 추출하는 과정이 명시되어 있으며, 페이지네이션 처리도 명확합니다.
88-143: 좋아요 등록 멱등성 처리가 적절함좋아요 등록 시 이미 존재하는 경우 중복 생성 방지(라인 133-136)와 상품 없음 예외 처리(라인 116-120)가 명시적으로 표시되어 있습니다.
148-199: 좋아요 취소 멱등성 처리가 적절함취소할 좋아요가 없는 경우 멱등성을 보장하여 오류 없이 성공 응답을 반환하는 설계(라인 189-192)가 좋습니다.
.docs/design/03-class-diagram.md (4)
1-71: 도메인 모델 설계가 명확하게 시각화됨Mermaid 클래스 다이어그램이 엔티티 간 관계와 책임을 잘 표현하고 있습니다. 양방향 연관관계(Brand ↔ Product, Order ↔ OrderItem)와 cascade 전략도 주석으로 설명되어 있습니다.
38-47: Order와 Member 관계 정의 확인 필요Order 엔티티가 userId를 String 타입으로 정의(라인 39)하고 있는 반면, Like 엔티티는 Member 객체 참조(라인 34)를 사용하고 있습니다.
ERD 문서(04-erd.md 라인 51)에서 orders.user_id를 FK로 정의했다면, Order가 Member 엔티티를 참조하도록 설계하는 것이 일관성 있을 것으로 보입니다.
확인 사항:
- Order가 Member를 직접 참조하지 않은 이유가 있는지
- user_id를 String으로 유지하는 대신 memberId 참조로 변경할 가능성
이는 라인 39 변경과 클래스 다이어그램의 관계선 추가(Order → Member)로 반영될 수 있습니다.
200-220: Point의 동시성 제어 명시 및 설계가 적절함Point 엔티티가 Member와 1:1 관계를 가지고 있으며, 비관적 락(pessimistic lock) 적용 대상으로 명시(라인 218)되어 있어 동시성 제어 전략이 명확합니다.
224-288: Value Object 설계가 일관성 있고 완전함Money, Stock, Quantity 등 VO의 불변성(Immutability), 검증(validation), 연산 메서드가 명확하게 정의되어 있습니다. 특히 음수 방지(라인 244, 267, 285)와 경계값 검증(Quantity 최소 1개)이 잘 명시되어 있습니다.
.docs/design/04-erd.md (6)
71-78: Point와 Member의 관계 명확화 필요points.user_id는 UK,FK로 정의되었으나(라인 73), 이것이 members.id(BIGINT)를 참조하는지, 아니면 members.user_id(VARCHAR UK)를 참조하는지 명확하지 않습니다.
설계 의도를 명시하기 위해 다음과 같이 수정을 권장합니다:
points { bigint id PK - varchar user_id UK,FK + varchar user_id UK,FK "references members(user_id)" bigint balance ... }또는 BIGINT 기반 FK를 사용하려면:
points { bigint id PK bigint member_id UK,FK "references members(id)" bigint balance ... }
105-148: members 및 products 테이블 설계가 적절함members 테이블의 soft delete 패턴(deleted_at, 라인 116)과 UNIQUE 제약조건(user_id, 라인 110), products의 비정규화된 likes_count(라인 144)와 동시성 제어 필요성(라인 151)이 명시적으로 기록되어 있습니다.
155-170: likes 테이블 설계 - 멱등성 보장 명시됨likes 테이블의 복합 UNIQUE 인덱스 필요성(라인 167)이 명시되어 있어, (member_id, product_id) 조합으로 중복 좋아요를 방지하고 멱등성을 보장합니다.
-- 암묵적 요구사항: 다음 제약조건 추가 필요 UNIQUE KEY uk_member_product (member_id, product_id)이를 테이블 설정에 명시하는 것을 권장합니다.
186-203: order_items 설계 - 데이터 무결성 고려 좋음order_items 테이블이 주문 당시 가격 저장(price, 라인 194)과 소계 저장(subtotal, 라인 195)을 분리하여 설계한 것이 좋습니다. 이를 통해 상품 가격 변동과 무관하게 주문 이력을 정확하게 보존할 수 있습니다.
224-240: point_histories 감사 추적 설계가 적절함point_histories 테이블이 거래 유형(transaction_type), 금액, 거래 후 잔액(balance_after)을 기록하여 포인트 변동을 완전히 추적할 수 있도록 설계되어 있습니다. 이는 재무 감시(audit trail) 요구사항을 잘 충족합니다.
1-99: ERD 관계선 정의 불완전 - 데이터 무결성 문제Mermaid ERD 다이어그램(라인 5-99)에서 다음 관계가 누락되거나 불명확합니다:
orders ↔ members 관계 누락
- orders 테이블이 user_id(VARCHAR) FK를 가지고 있으나(라인 51), 다이어그램의 관계선(라인 91-98)에 orders → members 관계가 정의되지 않았습니다.
points ↔ members 관계 누락
- points.user_id는 UK,FK로 정의되었으나(라인 73), 관계선에 points → members 관계가 정의되지 않았습니다.
이를 다음과 같이 수정하는 것을 권장합니다:
members ||--o{ points : "owns" points ||--o{ point_histories : "has" + members ||--o{ orders : "places" + orders ||--o{ order_items : "contains" + products ||--o{ order_items : "referenced in"라인 94-96 부분을 검토하고 위 관계들이 올바르게 정의되었는지 확인하세요.
Likely an incorrect or invalid review comment.
| ## 2. 내가 좋아요한 상품 목록 조회 | ||
|
|
||
| ### 시나리오 | ||
| 사용자가 자신이 좋아요한 상품 목록을 조회합니다. | ||
|
|
||
| ```mermaid | ||
| sequenceDiagram | ||
| participant Client | ||
| participant LikeV1Controller | ||
| participant LikeFacade | ||
| participant LikeService | ||
| participant LikeRepository | ||
|
|
||
| Client->>LikeV1Controller: GET /api/v1/like/products?page=0&size=20 | ||
| Note over Client,LikeV1Controller: Header: X-USER-ID | ||
|
|
||
| LikeV1Controller->>LikeV1Controller: X-USER-ID 헤더 검증 | ||
|
|
||
| alt X-USER-ID 헤더 누락 | ||
| LikeV1Controller-->>Client: ApiResponse(400, "X-USER-ID 헤더 정보 누락입니다.") | ||
| else 유효하지 않은 페이지 파라미터 (음수) | ||
| ProductV1Controller-->>Client: ApiResponse(400, "유효하지 않은 페이지 파라미터입니다.") |
There was a problem hiding this comment.
복사-붙여넣기 오류 수정 필요
라인 66에서 "ProductV1Controller"로 잘못된 컨트롤러 이름이 참조되고 있습니다. 문맥상 "LikeV1Controller"로 수정되어야 합니다. 이는 라인 53의 LikeV1Controller 시퀀스 다이어그램에서의 오류입니다.
- ProductV1Controller-->>Client: ApiResponse(400, "유효하지 않은 페이지 파라미터입니다.")
+ LikeV1Controller-->>Client: ApiResponse(400, "유효하지 않은 페이지 파라미터입니다.")📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## 2. 내가 좋아요한 상품 목록 조회 | |
| ### 시나리오 | |
| 사용자가 자신이 좋아요한 상품 목록을 조회합니다. | |
| ```mermaid | |
| sequenceDiagram | |
| participant Client | |
| participant LikeV1Controller | |
| participant LikeFacade | |
| participant LikeService | |
| participant LikeRepository | |
| Client->>LikeV1Controller: GET /api/v1/like/products?page=0&size=20 | |
| Note over Client,LikeV1Controller: Header: X-USER-ID | |
| LikeV1Controller->>LikeV1Controller: X-USER-ID 헤더 검증 | |
| alt X-USER-ID 헤더 누락 | |
| LikeV1Controller-->>Client: ApiResponse(400, "X-USER-ID 헤더 정보 누락입니다.") | |
| else 유효하지 않은 페이지 파라미터 (음수) | |
| ProductV1Controller-->>Client: ApiResponse(400, "유효하지 않은 페이지 파라미터입니다.") | |
| ## 2. 내가 좋아요한 상품 목록 조회 | |
| ### 시나리오 | |
| 사용자가 자신이 좋아요한 상품 목록을 조회합니다. | |
🤖 Prompt for AI Agents
.docs/design/02-sequence-diagrams.md lines 45-66: fix the copy-paste error where
the sequence diagram uses "ProductV1Controller" on line 66 but should reference
"LikeV1Controller"; update that controller name to "LikeV1Controller" so the alt
branch matches the rest of the Like flow and the error response line reads
LikeV1Controller-->>Client: ApiResponse(400, "유효하지 않은 페이지 파라미터입니다.")
| orders { | ||
| bigint id PK | ||
| varchar user_id FK | ||
| varchar status | ||
| bigint total_amount | ||
| timestamptz created_at | ||
| timestamptz updated_at | ||
| timestamptz deleted_at | ||
| } |
There was a problem hiding this comment.
데이터 타입 불일치 - FK 관계 정의 필요
orders 테이블의 user_id가 VARCHAR FK로 정의되어 있으나, members.id는 BIGINT PK입니다(라인 8).
두 가지 해결 방안:
옵션 1: members.id → orders.user_id로 통일 (권장)
- members.user_id(VARCHAR)를 FK 대상으로 지정하되, orders.user_id의 제약조건을 명시:
orders {
bigint id PK
- varchar user_id FK
+ varchar user_id FK "references members(user_id)"
varchar status
...
}옵션 2: orders에 member_id(BIGINT FK) 추가
orders {
bigint id PK
bigint member_id FK "references members(id)"
varchar status
...
}현재 설계에서는 orders.user_id가 members.user_id를 참조하도록 명시하는 것이 데이터 무결성 측면에서 더 안전할 것으로 보입니다.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| orders { | |
| bigint id PK | |
| varchar user_id FK | |
| varchar status | |
| bigint total_amount | |
| timestamptz created_at | |
| timestamptz updated_at | |
| timestamptz deleted_at | |
| } | |
| orders { | |
| bigint id PK | |
| varchar user_id FK "references members(user_id)" | |
| varchar status | |
| bigint total_amount | |
| timestamptz created_at | |
| timestamptz updated_at | |
| timestamptz deleted_at | |
| } |
🤖 Prompt for AI Agents
.docs/design/04-erd.md around lines 49-57: orders.user_id is defined as VARCHAR
but members.id is BIGINT (line 8), causing a type mismatch for FK relationships;
fix by making the FK relationship explicit and ensuring types match — either (A)
change orders.user_id to BIGINT and declare it as FK referencing members.id, or
(B, preferred) ensure members exposes a VARCHAR user_id primary/unique key and
add an explicit FK constraint on orders.user_id -> members.user_id (and document
the constraint in the ERD); update the column types and add the FK notation so
the ER diagram unambiguously enforces referential integrity.
1 participant
📌 Summary
💬 Review Points
✅ Checklist
📎 References