[과제] Spring e-Commerce back office Task Day 3

https://github.com/Hyeonseok-Homies/Spring_e-commerce-back-office

GitHub - Hyeonseok-Homies/Spring_e-commerce-back-office

 

필수는 끝났고, 도전과제 중에서 내가 개발을 담당한 요구사항

3. 리뷰 정보 관리

1️⃣ 목적

고객이 작성한 상품 리뷰를 조회하고 관리하여, 부적절한 리뷰를 삭제하거나 리뷰 데이터를 마케팅에 활용합니다.

2️⃣ 요구사항

[리뷰 리스트 조회]

다음 쿼리 파라미터를 지원해야 합니다.

• 검색 키워드 (고객, 상품명)
• 페이지 번호 (기본값: 1)
• 페이지당 개수 (기본값: 10)
• 정렬 기준 (예: 평점, 작성일)
• 정렬 순서 (asc, desc)
• 평점 필터 (1~5)

응답에는 다음이 포함되어야 합니다.

• 리뷰 목록
  • 고유 식별자(ID), 주문번호, 고객명, 상품명, 평점, 리뷰 내용, 작성일
• 페이징 정보 (현재 페이지, 페이지당 개수, 전체 개수, 전체 페이지 수)

[리뷰 상세 조회]

• 특정 리뷰의 상세 정보를 조회합니다.
  • 상품명, 고객명, 고객 이메일, 작성일, 평점, 리뷰 내용
• 존재하지 않는 ID 요청 시 에러를 반환합니다.

[리뷰 삭제]

• 부적절한 리뷰를 관리자가 삭제할 수 있습니다. 

 

개발전 정리

엔티티 필드 값 :

필드갑별로 데이터 검증

고유 식별자(ID) id

주문번호  orderNumber

고객명 customerName

상품명 productName 

평점 grade  

리뷰 내용 reviewContent

작성일 수정일 -> 기존 BaseEntity 활용

DTO 

들어오는 입력값 검증

reviewRequestDto, reviewResponseDto

review DetailsRequestDto, review DetailsResponseDto

reviewDeleteRequestDto, reviewDeleteResponseDto

 

컨트롤러 패키지(API)

들어오는 데이터 파싱 자동화 생각해보기

공통 /api/review

GET ->페이징 

GET /id

DELETE /id 

 

서비스패키지

로직내 비지니스 로직 검증(권한,로그인여부)->기존에 LoginArgumentResolver 클래스 활용해보기

getReviewAll->로그인 되어있는지 (관리자 이면 상관없음) 확인하기, 조회시 리뷰가 없으면 없다고 오류반환하기,

고유 식별자(ID), 주문번호, 고객명, 상품명, 평점, 리뷰 내용, 작성일 응답하기

getReviewDetail-> 로그인 되어있는지 (관리자 이면 상관없음) 확인하기 , 조회시 리뷰가 없으면 없다고 오류반환하기,상세 조회시상품명, 고객명, 고객 이메일, 작성일, 평점, 리뷰 내용 응답주기

deleteReview-> 로그인 되어있는지 (관리자 이면 상관없음) 확인하기,삭제시 없는 리뷰이면 오류 반환하기, 하드삭제/소프트 삭제 전략 선택하기

 

튜터님 피드백

1. 코드 품질 및 리팩토링 (Clean Code)

• 네이밍 규칙: 에러 처리 클래스는 Error보다 Exception 접미사를 사용하여 직관성을 높일 것.
• 리소스 최적화: 사용하지 않는 클래스, 메서드, import문은 즉시 삭제하여 코드의 가독성을 확보할 것.
• 중복 제거: findById와 같은 반복 로직은 private method나 인터페이스의 default method를 활용해 공통화할 것.
• 설정 분리: JPA Auditing 등 설정 정보는 별도의 Config 클래스로 관리하여 설정과 비즈니스 로직을 분리할 것.

2. 객체 지향 및 데이터 정합성 (OOP & Integrity)

• 정적 팩토리 메서드: 생성자 대신 의미 있는 이름의 정적 메서드를 사용하여 객체 생성의 의도를 명확히 하고 DTO-Entity 변환 시 유지보수성을 높일 것.
• 객체 스스로의 통제권: Order의 totalPrice처럼 계산이 필요한 필드는 외부에서 주입받지 말고, 객체 내부에서 스스로 계산하도록 하여 데이터 신뢰도를 확보할 것.
• 데이터 검증(Validation): 수정(Update) 시에도 중복 체크(Email 등)는 필수이며, Bean Validation 등을 활용해 입력 단계부터 데이터의 안정성을 보장할 것.

3. 기술 선택의 기준 (Strategy)

• 조회 전략: 검색 조건의 복잡도에 따라 명확한 기준을 세울 것.
  • 단순 조회: 쿼리 메서드
  • 복잡/동적 쿼리: QueryDSL (권장: 타입 안정성 및 빌드 시점 오류 확인 가능)
• 삭제 전략: 주문 데이터 등 연관 관계가 있는 데이터를 삭제할 때의 DB 정합성을 반드시 고려할 것. (완전 삭제 vs 논리 삭제 전략 중 선택)

4. 핵심 과제: 동시성 (Concurrency)

• 주요 과제: "동일 시간에 1개의 상품을 여러 명이 주문할 때" 발생하는 이슈 파악.
• 학습 포인트: 자바의 멀티쓰레딩 환경과 스프링 빈(Singleton)의 특성상 왜 동시성 제어가 필수적인지 깊이 있게 파고들 것.

 

이번 과제 진행간 튜터님의 많은 피드백으로 좀더 나은 개발을 위한 생각을 하게되었다.

그리고 반복 코딩을통해 기본 설계와 코드를 어떻게 작성할지 머릿속에 그려지기 시작한다!

물론,, 앞으로 새로운 과제를 경험하면서 쉽지는 않겠지만 달려보자잇!

 

19일 전까지 담당 개발 내용 모두 완료하기, 19일날 팀원들과 깃 PR과 MERGE 진행하기