찜 기능에서 의문점
찜한 목록 조회나 찜하기 등에서 궁금한 점이 생겼는데요.
찜한 목록 자체가 찜한 상품 목록일텐데 그렇다면 찜 목록 조회 시 찜한 "상품" 데이터 목록을 응답해주어야 하는게 아닌가요? 상품의 아이디만 반환해주고 클라이언트에서는 해당 상품 id 목록으로 상품 목록을 재 조회하는 등의 방식으로 설계하신건지... 궁금합니다.
또 찜하기에서는 상품이 실제 존재하는 상품인지에 대한 검증이 없는 것 같은데 이 내용은 상품의 개념이기에 표현되지 않은 것일까요? 실제 존재하는 상품에 대해서만 찜하기가 가능하다. 라는 내용또한 개념으로 작용할 수 있는 것일까요?
답변 1
0
안녕하세요 질문 감사드립니다!
해당 부분은 말씀해주신 내용이 맞습니다ㅎㅎ 이상함을 느끼시는 분들이 있을 거라 생각했는데 이제야 질문이..! 코드 꼼꼼히 보시고 고민하고 계시는 것 같아서 아주 기쁩니다!
(만약 클라이언트가 그렇게 API 를 나눠자고 요청했다면 이건 무조건 설득해야하는 영역 같습니다 😃)
추가로 찜하기에 상품이 존재하는지 내리는 영역은 찜하기 개념에서 검증이 가능하다고 생각합니다.
(개념 정리상 찜은 상품을 알고 있으니까요!)
찜은 실존하는 상품에 대해서만 찜이 가능하다는 전제가 맞아보입니다!
그래서 찜 정보는 있는데 상품이 없다면논리적 오류로 봐야할 것 같습니다
대신! 상품이 삭제된 상태라면 어떻게 노출할 것인지? 찜 목록 응답에서 아예 제외할 것인지? (그러면 페이징은....?)
아니면 "삭제 된 상품입니다." 로 고객에게 보여줄 것인지? 에 대한 요구사항의 정의가 필요할 것 같습니다!
모쪼록 답이 되었길 바랍니다! 완강까지 화이팅입니다!
페이징 처리에서 offset/limit에 대한 질문
1
56
1
usecase 사용 기준
1
68
2
궁금한점이 여러개 생겼습니다.
1
83
1
다양한 관점의 코드 경험을 위해 개선하지 않은 코드
1
73
1
histories() 응답에 PointHistory.id를 포함한 이유가 궁금합니다/
1
57
2
SettlementTargetRepository Jquery 질문
1
63
2
부가 기능을 이벤트 핸들러로 분리하는 기준이 있을까요?
1
75
2
엔티티의 pk 를 0으로 초기화하시는 이유가 있을까요??
1
84
2
제미니님 안녕하세요!
1
90
2
개념 간 격벽 분리와 목록 조회 시 발생하는 참조 구조
1
96
2
프로덕트와 프로덕트카테고리 사이의 삭제 정책
1
90
2
새로 개발한다면 구현 순서
1
154
1
의존 방향에 대한 고민
1
137
2
어드민(Back-office)에서 예약 변경 시, '할인 조건 재검증(쿠폰 회수)' vs '기존 혜택 유지' 중 어떤 정책이 일반적인가요?
1
109
2
OrderKeyGenerator 인스턴스화 generate() 질문
1
92
1
외부 API 통합 시 데이터 제어 범위 설계 질문
1
107
1
PG 결제 승인 로직
1
149
2
QnA에서 Join 필드 표현법
1
105
1
결제서비스 콜백 동시성문제 가능성
1
121
2
굿
1
117
1
도메인/엔티티 분리 상황에서 쓰기 작업 하는 방법
1
143
2
도메인 객체와 엔티티 객체 사용
1
151
2
CouponService 의존성 의문
1
109
2
상품 목록 조회 고도화 질문
1
120
2