안녕하세요.저도 개인 프로젝트로 이커머스를 만들면서, 결제와 같은 외부 API를 호출하는 부분에 대해서 많은 고민을 하게 되는 것 같습니다.가령, 결제 승인을 위해 PG API를 호출한 이후 결제 내역을 DB에 저장한다던가..혹은 결제 처리 이후 진행되어야 할 비즈니스 로직(배송 생성, 재고 차감 등..)을 진행해야한다던가..하지만 외부 API를 호출한다는 것은 사실 비즈니스 로직의 트랜잭션과 묶일 수 없다는 것이 참 어려운 것 같습니다.PG API 호출에 성공했지만, 이후 비즈니스 로직이 실패된다면 결제 강의 - 코드느끼기에서 말씀해주신 것 처럼,사용자의 돈은 빠져나갔지만, 배송 처리가 되지 않거나 그런 일이 발생할 수 있을 것 같아요.혹은 PG API 호출 시에, 타임 아웃이 발생해서 실패했다고 판단했지만, 알고보니 PG 서버 상으로는 승인이 정상적으로 처리 된 경우도 있을 것 같아요.이처럼 외부 API 연동 시에 데이터 정합성을 고려하는 것이 엄청 어려운 것 같습니다. 그래서 저는 결제처럼 사용자의 돈을 처리해야하는 경우 세부적인 방어 로직이 필요할 것 같다는 생각을 합니다.그래서 고민을 하면서, 이것저것 찾아보다가 사용하게 된 패턴이 외부 API를 요청하기 전에, state를 추가해서 관리하자 라는 것이었는데요. 예를 들어 결제로직의 경우 결제 검증을 처리하고 승인 API를 호출하기 전에 Payment의 State를 PENDING_PG_REQUEST(예시)로 변경한 뒤, PG API를 호출하는 흐름입니다. 만약 PG API 호출에 정상적으로 성공했지만, 결제 후처리 비즈니스 로직에 실패했더라도,스케줄러 같은 걸 통해 특정 시간 동안 계속해서 PENDING_PG_REQUEST인 결제 건이 있다면, 이것은 적어도 PG API를 호출하고 나서, 무언가 잘못되었다는 것이니까, 데이터 정합성을 맞춰주기 위해 한번 더 직접 API를 호출하고 나서 비즈니스 로직을 추가적으로 실행시켜주는 그런 작업을 진행해주면 될 것 같아요.이런 패턴이 어떻게 보면 강의 코드 예제에서 정산을 처리하는 SettlementService의 transfer 메서드와 비슷하다고 생각합니다. Settlement Entity에 Ready인 데이터를 결국 주기적으로 처리하면서, 언젠가는 정산 처리를 진행하게 되니까요!근데 문득 제가 사용하는 방식, 그리고 transfer 메서드의 방식은 특정 조건이 충족해야한다는 점이 있는 것 같아요. 사용하는 외부 API가 멱등성을 제공해야하고, 데이터 정합성을 처리하기 위해 돌아가는 스케줄러,배치 또한 자체적으로 중복처리 방지를 방지해야 한다는 것을요...이렇게 생각하다보니 끝도 없이 딥해지고 복잡해지는 것 같아서, 문득 다시 결제 부분 강의를 보다보니,수기 처리 방식도 아주 잠깐 언급하셨더라구요. 문제가 발생했을 때 로그를 남겨놔서, 데이터를 비교 후 데이터 정합성을 맞춘다. 근데 돈과 관련된 부분은 그 즉시, 성공 실패에 대한 처리를 해줘야할 것 같기도 하고 이 부분만큼은 과하게 방어 로직을 작성하는 게 맞을까?라는 생각이 들게 되는 것 같아요. 그리고 만약 외부 API가 멱등성을 제공하지 않으면어떻게 처리해야하지?라는 생각이 들기도 하고요.재민님께서는, 이런 외부 API 연동과 데이터 정합성을 고려해야할 때 방어 로직을 깊게 생각하시는지 궁금해서 질문을 하게 되었습니다. 근데 사실 돈과 관련된 부분은 아무리 생각해도 많은 방어 로직을 필요로 하는 것은 당연한 것 같긴한데, 어느 정도로 처리를 해줘야할 지 모르겠네요. 하하..최소한의 방어로직, 그리고 예외, 실패 시 로깅 처리로 모든 가능성을 추적해야 하는 게 효율적일까요??감사합니다!

강의에서 상품 상세 컨트롤러에서 여러 개의 서비스를 직접 참조해 하나의 응답으로 반환하고 있는데요이 경우, 단일 서비스에서 데이터를 묶어 응답하지 않고 각 서비스를 개별적으로 호출하는 이유가 궁금합니다.이런 구조가 모듈을 분리했을 때 Aggregation 성격의 서비스가 여러 서비스에 의존하게 되는 문제를 피하기 위한 설계인가요?또, 여러 서비스를 호출하면 하나의 API 요청 내에서 여러 트랜잭션 커넥션이 열릴 수 있는데, 이를 설계 상 트레이드오프로 봐야 할까요?추가로, 강의에서는 productId 하나만 받아서 여러 서비스를 독립적으로 호출하고 있는 것 같았는데,서비스 간 호출 순서가 없으므로 각각을 독립적인 유즈케이스로 보는 게 맞을까요?아니면 컨트롤러가 여러 서비스를 조합하는 역할을 가져도 되는 걸까요?마지막으로, 저는 조회 시 실무에서는 모듈별 유즈케이스가 각각 존재하고, 이를 묶어주는 별도의 서비스가 로직과 조합을 포함하여 담당하고 있습니다.예를 들어 상품 조회 API 응답 시 상품내용과 함께 회원 이름/생년월일 등등 포함, 쿠폰 정보 포함 요구사항이 주어졌을 때두 가지 방식으로 구현할 수 있을 것 같은데요어떻게 바라보시는지 궁금합니다.# 방법1 # 특정 서비스에서 조합하여 호출 상품 API 모듈(컨트롤러) → 상품 Service 모듈 → 회원 모듈 서비스1, 쿠폰 모듈 서비스2, ...# 방법2 # 각 서비스를 컨트롤러에서 호출 상품 API 모듈(컨트롤러) → 회원 모듈 서비스1, 쿠폰 모듈 서비스2강의에서는 방법2 와 비슷하게 처리하신 것 같습니다.강의 중 여러가지 패턴을 소개해 주신다고 했지만 급하게 질문드리는 점 죄송합니다.

현재 실행 계획이 강의랑 반대라서 질문 남겨봅니다 드라이빙 테이블이 de 로 나오는 이유가 뭘까요 ?

안녕하세요! 날짜 수정 관련해서minusDays를 변경하는게 어째서 불편한건가요?안에 들어가는 파라미터만 바꿔주면 되는데 불편해지는 부분이라는게 잘 이해가 안되네요

시스템이 힘들어 하지 않을까요?가입 유저가 1만명 2만명 올라가면 거기에 따라서 인벤토리 테이블 행들도 엄청 많아질텐데요,, 

올려주신 다른 주요 개념들에서 조회에는 트랜잭션이 별도로 걸려있지 않았었는데, Order 쪽은 getOrders 와 getOrder 모두 트랜잭션이 걸려있더라구요!  혹시 이쪽에만 특별히 트랜잭션을 걸어주신 이유가 있나요? 감사합니다.

안녕하세요!findSections의 return부분을 떼어다가 ProductSectionSevice에 옮기는 부분이 있는데옮기기 전과 후의 차이가 어떤 차이가 있는건지 알 수 있을까요? 저의 실력이 부족해 잘 이해가 되지 않아 질문드립니다.

안녕하세요 강사님, 덕분에 입문부터 기초까지 듣게되었으며, 추후 설계부분도 들으려 결제를 해놓은 상태입니다. 지금 상용 서비스에 mysql과 fastapi를 활용하여 서버를 구축하려 하는데, 궁금증이 생겨 문의 드립니다. mysql의 용량은 저희 서버의 용량이 허락하는 한 무료로 활용이 가능한지?서버에서 db에 연동해서 데이터를 불러올 때, 최대한 sql문법을 활용하는지? 아니면 상황에 따라 모든 데이터를 불러와서 서버내 프레임워크에서 정제를 하는지?이외에도 주의할 사항이 있는지? 혼자하는 진행하는 프로젝트기에 생각과 걱정이 많았지만, 강사님이 한 줄기 빛으로 다가왔습니다. 위 질문에 답변해주시면 감사하겠습니다.

 상단의 스크린샷이 저의 로컬에서 확인된 거구요아래는 선생님의 결과 입니다  [실습] 유저 이름이름 특정기간에 작성된 글 검색하는 SQL문 튜닝하기3:30초 구간 입니다 똑같이 했는데 왜 TYPE과 KEY 변경되어 있을까요?제가 잘못하고 있는건가요? 따라 쓴거도 아니고 NOTION에 있는걸 복붙 했습니다 ;;; 

안녕하세요! 수업 중에 재민 님이 말씀해주신 이미 다운로드 한 쿠폰은 내려주지 않는 것과 관련해서 질문이 있습니다.제 나름대로 생각해 본 코드는 이렇습니다.fun getCouponsForProducts(productIds: Collection<Long>): List<Coupon> { val productTargets = couponTargetRepository.findByTargetTypeAndTargetIdInAndStatus( CouponTargetType.PRODUCT, productIds, EntityStatus.ACTIVE, ) val categoryTargets = couponTargetRepository.findByTargetTypeAndTargetIdInAndStatus( CouponTargetType.PRODUCT_CATEGORY, productCategoryRepository.findByProductIdInAndStatus(productIds, EntityStatus.ACTIVE).map { it.categoryId }, EntityStatus.ACTIVE, ) val applicableCouponIds = (productTargets + categoryTargets).map { it.id }.toSet() val downloadedCouponIds = ownedCouponRepository.findByUserIdAndState(userId, OwnedCouponState.USED) # userId 어디서 받아오지? .map { it.couponId } .toSet() val finalCouponIds = applicableCouponIds - downloadedCouponIds if (finalCouponIds.isEmpty()) { return emptyList() } return couponRepository.findByIdInAndStatus(finalCouponIds, EntityStatus.ACTIVE) .map { Coupon( id = it.id, name = it.name, type = it.type, discount = it.discount, expiredAt = it.expiredAt, ) } }여기서 고민됐던 부분은 findByUserIdAndState 에서 userId 를 어디서, 어떻게 받는 것이 좋을지 입니다. getCouponsForProducts 함수가 호출되는 ProductController의 findProduct 메서드에서는 별도의 User 관련된 정보를 받아오지 않기 때문에 userId 를 받아올 수 없는 상황인 것 같습니다. 그런데 유저가 자신이 이미 다운로드 한 쿠폰을 중복해서 '다운로드 가능 쿠폰' 목록에서 보이지 않게 하는 소위 '개인 맞춤' 작업은 User가 꼭 필요한 정보라고 생각 되는데요.이런 경우에 findProduct에 CouponController에서 처럼 User를 바로 넘겨주면 간단(?)하게 userId를 알 수는 있지만 이게 최선인 것 같진 않습니다. User를 파라미터로 넘겨주는 것을 인증 절차를 거친다고 생각해본다면 상품 상세 정보 보는 것은 꼭 인증을 하지 않더라도 볼 수 있어야 할테니까요. (그런데 User를 파라미터로 넘겨주는 것이 인증이 된 사용자만 이 API를 사용할 수 있다고 이해하는 것이 옳은 이해인지는 제가 잘 모르겠습니다🥹)그래서 또 다른 접근법으로는 재민 님이 ProductController의 findProduct 메서드에서 쿠폰을 불러오는 부분 위에 주석으로 처리해놓으신 것처럼 별도의 API를 만들고 해당 API에서 User를 활용해서 진행하면 어떨까 하는 생각도 해봤습니다. 재민 님은 어떤 식으로 푸실지 궁금합니다! 감사합니다. 

안녕하세요!강의 중 잘 이해가 안되는 부분이 있어 질문드립니다.카테고리에 상품이 있는 방향으로 설명을 진행하다가 실제 구현에선 프로덕트의 카테고리이다 라고 정의를 하셨다고 말씀해주셨는데설명과 실제 구현이 다른 이유가 있을까요?

"실전 개념적 모델링 - 시작" 파트를 들으면서 궁금한 점이 있어 질문드립니다. 주문, 결제 엔티티의 경우, 주문은 '결제'까지 포함하는 비즈니스 트랜잭션 단위라 하였는데, 왜 두개의 엔티티로 분류해야하는지 궁금합니다.현재 요구사항에서는 하나로 합쳐도 문제가 없는건가요?

섹션1 강의에서 4강 '아나콘다와 주피터 노트북의 이해' 강의부터 강의 실행이 안됩니다.검정색 화면만 나와요... 해결방법 확인 부탁드립니다.

안녕하세요 🙂 지난번에 이어 질문을 또 남기게 되었습니다 ㅎㅎ 1. Point 라는 개념을 다룰 때 PointService에서 로직을 처리하지 않고 별도의 PointHandler라는 객체를 만들어서 처리하는게 Point 개념 자체가 다른 개념에서도 많이 사용하는 개념이다보니 PointService에서 처리하게 되면 Service 간 참조가 생기는 것을 방지(?) 하고자 이런 전략으로 처리한 것일까요? 이런 식으로 격벽을 넘어서 여러 개념에 걸쳐 있는 개념을 다룰 때는 별도로 분리해놓는 것이 재사용성, 응집 측면에서 좋은 전략인지 궁금합니다! 2. 지금 Point 변화를 주는 것을 PointBalanceEntity 에서 처리하고 있는데 만약 추후에 복잡한 포인트 적립 정책이 생긴다면 별도의 PointPolicy 를 Object 클래스로 만들어 해당 클래스에 포인트 적립 관련 로직을 응집 시키는 식으로 PointPolicy 라는 개념을 추가하는 건 어떻게 생각하시는지 궁금합니다! 감사합니다😀

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오) 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예[질문 내용]안녕하세요, 강의 잘 듣고있습니다.최근 파티셔닝이란 개념에대해 알게되었는데, 강의 내용엔 파티셔닝이 포함되어있지 않는 것 같아서 실무에서는 파티셔닝은 잘 사용하지 않는지 인덱스와는 어떤 차이가 있는 지, 파티셔닝을 실무에서 사용하지 않는다면 어떤 이유 때문인지 궁금합니다. 제가 검색 등으로 정보를 취득해봤을 땐, 주로 인덱스보다 더 큰 규모의 데이터를 다룰 때 파티셔닝을 쓰고 인덱스+파티셔닝을 함께 쓰면 더 좋은 결과를 얻을 수 있다는 것 같은데 실무에서도 해당 내용이 맞는 지도 궁금합니다.

안녕하세요! 금액 계산은 클라이언트 조작 문제 떄문에 서버에서 담당해야한다고 말씀해주셨는데요, 그렇다면 클라이언트에서는 식별값만을 주고 가격정보는 주지 않았을 때 문제는 없을까요? 예를 들어 클라이언트가 한 화면에서 오래 머무르는 동안 상품 가격이나, 할인 등 총 결제 금액을 계산하는데 있어 변동 사항이 생겼을 때 클라이언트가 보고 있는 가격과 서버에서 요청 시점에서 계산한 가격이 일치하는지까지 봐야하지 않나라는 생각이 들어 질문드립니다..! 서버에서 현재 상태를 기준으로 가격을 계산하고 처리했을 때, 사용자 입장에선 자신이 본 가격과 다른 가격으로 계산될 수도 있지 않을까요??가격을 결정짓는 요소들이 변경되었는지를 서버에서 판단해서 요청 실패처리를 할 수 있겠지만, 요소들이 많다면 각각을 버저닝하고 확인해야 하는 형태가 될 거 같기도 해서.. 클라이언트에서 확인한 가격 정보를 서버에 넘기고, 서버에서 실시간으로 계산한 금액과 일치한다면 성공시키는 구현 형태는 실무에서 잘 쓰지 않는 것인지 궁금합니다!

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]여기에 질문 내용을 남겨주세요. mysql을 다운 하라는 곳에 들어가 제대로 다운 했는데 화면이 강의에서 보는 것과 달라 맨붕이 옵니다. 다시 다운을 해도 똑같은 화면입니다 버전도 용량이 큰거도 다운했습니다. 어떻게 해야할까요..

서비스들을 보면 어떤 경우는 finder같은 서비스 하위 계층을 통해 도메인(개념)객체를 활용하기도 하고, 서비스에서 직접 repository를 의존해서 jpa entity를 활용해서 로직을 수행하는 케이스도 있어 보입니다! 혹시 서비스 단에서 도메인 객체를 가져와서 사용하는 것과 jpa entity를 직접 활용하는 것의 판단 기준이 따로 있으실까요?

이 명령은 actor.id 를 생성하는 명령인지. 아니면 gactor.get("id") 인지 궁금합니다.

현재 코드상으로 목록조회에서도 개념객체를 활용하는 것으로 확인했습니다! 하지만 한 개념 객체가 여러 개념 객체를 포함하는 경우가 있는 상태에서 페이지네이션 같이 모든 개념객체의 필드를 채워줄 필요가 없는 경우도 있을 거 같습니다. 이때,  필요한 컬럼만 추출한 데이터를 담는 별도 dto용 객체를 만든다개념 객체의 일부를 채운 값을 Page에 반환한다 실무에선 둘 중 어느 방식을 적용하는지 궁금합니다! 제 생각에는 개념(도메인) 객체는 항상 완전한 상태로 있어야 하므로 별도 프로젝션 dto용 객체를 만들어서 서비스단에서는 도메인 객체가 아닌 해당 dto 객체를 내려주는 것이 낫지 않을까 생각합니다. 또한 사용하지 않는 필드를 완전한 객체 상태로 만들어주기위해 불필요하게 많은 추가 쿼리가 발생할 수 있어서 이런 경우는 별도 값(dto)객체를 쓰는 게 나을 거 같은데 실무에서는 어떻게 하는지 궁금합니다!