PG 결제 승인 로직

안녕하세요 질문 감사드립니다![질문1]일반적으로 외부 시스템을 100% 신뢰할 수 없고 결제 요청(결제 생성 API 부분)이 만약 버그가 발생했을 때, 또는 정말로 가능성이 적지만 PG 시스템의 버그를 대비하여서 교차로 검증하는 것은 안전성을위해 추가해두면 편이고, 추가하는 것이 좋을 것 같습니다!만약 PG사에서 넘어온 정보와 다를 경우는 아직 승인API를 보내지않았기 때문에 고객의 돈이 빠지지 않은 상태이고, 결제에 대해서는 에러로 처리를 해야할 것 같습니다이 부분은 결제 생성 or 시스템의 버그에 대한 부분이기 때문에 보정이 가능한 부분이아니고, 클라이언트에게 에러를 내려주면 고객에게도 에러 상황에 따른 적절한 안내 페이지가 나타나면 될 것 같습니다!(결제 영역이다보니 임의로 승인API가 호출하게 되면 치명적인 장애로 이어질 수 있을 것 같습니다!) [질문2]서킷 브레이커를 사용하는 것은 전략적인 선택이 필요합니다그래서 단순히 선호에대한 것으로 접근하기보다는 상황에 맞춰서 유무를 결정하는 것이 좋다고 봅니다!결제를 간단히 예로들면 만약 A 카드사의 결제 지분이 높은데 A카드사의 장애가 발생해서 장애 전파가 일어났을때, 단순히 그 정보로 서킷이 열려서 전체 결제수단의 결제가 안 된다고 생각하면 심각한 문제라고 볼 수 있는것이죠이렇듯 서킷은 상황과 전략에 따라 적절한 판단이 필요할 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

QnA에서 Join 필드 표현법

안녕하세요 질문 감사드립니다! 아주 좋은 질문입니다! 😃사실 일반적인 상황에서는 1번의 방향성이 쉽게 접근가능하고 명확함이 올라간다고 생각합니다다만 꼭 User클래스를 갖지 않더라도 author 라는 필드로 갖고 있을 수도 있을 것 같습니다그런데 우리 강의의 정의한 시스템 상황에서 문제가나 하나 발생합니다지금 우리 상황에서는 User에 대한 데이터를 별도 UserService 와 UserDB로 분리하여 운영하고 있습니다즉 우리가 예제 코드로 바라보고 있는 곳에선 UserDB를 접근하지 못하고 UserName을 알고 싶으면 API로 가져와야합니다 😅이 상황이라서 2안으로 가더라도 UserService의 API를 호출해서 목록을 조합해야하기 때문에 UserService API가 성능이 느려진다면 QnA목록 조회 API도 느려지게 되는 문제가 생기게 됩니다. 그래서 현실적으로 우리 상황에서 해당 요구사항을 처리하려면 Question을 추가할때 userName을 DB에 추가하도록 해야 할 것 같습니다 (Answer의 경우는 관리자 등록 이므로 제외 가능 할 듯하네요)(물론 UserService의 User정보를 동기화 시켜두는 전략도 있지만 그 전략은 이것 때문에 작업하기에는 다소 과하지 않나 싶단 생각이 듭니다) 또 추가적으로 이 작업을 하려면 G/W단에서 UserName을 같이 넘겨주는 작업을 해야할 것 같습니다(현재 가정은 UserId만 넘겨주는 상태)이 강의에서는 해당 내용을 추가하면 집중을 의도하고자한 부분이 흐려지기 때문에 제외했습니다 그래서 우선 ID만 내려주도록 구성해두었습니다!이런 전략은 이번 강의의 메인 주제와 벗어나긴하지만 충분히 생각해볼 수 있는 부분인 것 같습니다 😃좋은 질문 감사드립니다! 모쪼록 답이 되었길 바랍니다! 감사합니다!

결제서비스 콜백 동시성문제 가능성

안녕하세요 질문 감사드립니다!이 부분은 상당히 애매하기 때문에 서비스 기획 담당하고도 소통이 필요합니다주문 결제 전 단계에서 막는다 를 선택하더라도, 카드사 결제창을 동시에 띄워놨다가 결제한다면 이미 우리 서비스에선 알 수가 없습니다즉 이것은 만약 고객이 의도해서 쿠폰이나, 포인트를 더 쓰려했다면(어뷰징으로 볼 수 있음)오히려 어떤식이든 문제가 발생해서 확인이 가능한게 맞다고 생각합니다이런 부분이 기획 쪽하고 소통이 되어야할 것 같습니다 그렇다고 아예 주문창에서결제 버튼을 눌렀을때 포인트나 쿠폰을 선 차감 하는 전략을 쓰기에도 서비스 이용 측면에서 상당히 모호합니다, 그럼 특정 시간이후 선 차감 한 부분을 다시 반환해줘야하고 이에 대해서 고객은 구매를 안하고 이탈 할 수도 있습니다(ex] 카드 + 10,000포인트 사용 -> 결제 버튼 누름 -> 포인트 선차감 처리 -> 카드사결제 창까지 갔다가 -> 까먹은 상품이 있어서 다시 주문을 하려함 10,000포인트는 10분 뒤에 복구 됨 -> 고객은 기다리다가 짜증이나서 꺼버림, 또는 원하던 상품 품절되어 강성 민원 재기)이와 유사한 방식으로 영화관 예매, 비행기 좌석 예매, 미용실 예약 등 선 차감 방식을 쓸 때 생기는 느낌의 문제들이 있습니다.아무튼 success API의 PG사 승인 API를 호출하기 전에 validation을 추가하는 것은 가능 할 것 같습니다다만 이 부분도 여전히 타이밍 이슈가 존재합니다우선 현재의 경우는 쿠폰과 포인트 사용에 대하여 낙관적 락이 적용되어 있는 상태입니다그래서 최종 충돌에 대하여 대비가 되어있는 상태라고 봐주시면 될 것 같습니다이제 타이밍 이슈 상황을 다시 정의해보면 이렇습니다한명의 유저가여러개의 주문을 생성해서포인트와 쿠폰을 여러 주문에 중복 적용한다 여기 부터 어뷰징의 의심이 생기기 시작합니다물론 가족과 아이디를 공유하는 환경일 수도 있습니다..!여러 주문에 적용하기 위해 완벽히 동일한 시간(ns)으로 결제를 한다네트워크 회선 등의 문제가 없어서 운좋게 콜백까지 동일한 시간에 온다validation 및 예외처리하는 로직은 통과한다아직 여러 주문의 callback 중 쿠폰이나,포인트 처리를 하지 못 했기 때문에낙관적 락 충돌로 예외가 발생한다결국 이 상황은 의도 된 어뷰징 또는 정말 완벽한 우연의 일치라 보고 문제가 생길 수 있기 때문에 수동 처리 또는 빈도가 적지 않다면 우리 디비 결제 상태와 PG결제 상태를 비교해서자동 취소 처리 배치 등 운영 자동화으로 풀어낼 수 있다고 봅니다.요약하면 success api 에 validation 과 예외 처리를 추가하는 것은 유의미하다고 생각합니다주문 결제 전 단계에서 막는 것은 현실적으로 불가능한 부분이 많다고 봅니다다만 결국 이 케이스는 동시성 경합이 일반적으로 일어나지 않아야 정상이라고 보기 때문에 정상적인 유저에게서 발생할 가능성이 적은 케이스라고 보는게 좋다는 생각입니다모쪼록 답이 되었길 바랍니다! 완강 후 수강평도 기대하겠습니다! :D

굿

안녕하세요! 제가 강의를 만들 때 수강생분들이 그런 느낌을 받으셨으면 좋겠다 생각했는데 그렇게 느끼셨다니 매우 기쁩니다! 완강까지 화이팅 부탁드리고 완강 후 수강평도 기대하겠습니다!!

도메인/엔티티 분리 상황에서 쓰기 작업 하는 방법

안녕하세요 질문 감사드립니다!의도적으로 훈련을 하고 계시는 군요 아주 멋집니다! 👍 계속 해보시면 느끼시겠지만 결국.. 모든 상황을 완벽히 만족시키는 방법은 없습니다😄그래서 그 속에서 트레이드 오프를 생각해서 타협하여 전략을 결정하셔야합니다!불필요한 리스트를 조회해서 채워주던가nullable 을 허용하던가수정에 대한 클래스를 만들던가등등 몇몇 방법이 더 있을듯저 또한 이에대해 각각 케이스별로 만들어보고 차이점을 느껴봤었기에 나름의 전략을 세웠습니다우선 저는 nullable 허용을 안한다가 타협 없는 지점 입니다그러면 이제 선택지가 좁혀지죠PostCommentsImages이런 구조라 했을때 Post 를 가져올 때마다 Comments, Images 를 다 채워야한다면 비효율이 있는게 맞습니다조회 영역을 타협하겠다면 Post가 Comment나 Image를 기본적으로 모르게하고 필요한 영역에서 조합하도록 사용할 수 있을 것 같습니다 (ex] Presentation Layer)그치만 연관 개념들이 잘 모여있는 구조를 유지하고 하고싶고, 저 조합하는 전략이 싫다면 어쩔 수 없이 매번 채워야겠죠 😃 (강의에서도 유사한 구조가 몇 번 있었던 것 같습니다)다음 전략 후보로는 수정에 대한 필드를 갖는 수정 개념 객체를 만든다 적어주셨는데이것도 괜찮은 전략 중 하나입니다 대신 수정용 도메인 이런 느낌으로 접근하기 보다는 행위/책임 자체에 집중하여 클래스를 구성해서 구현해보시면 느낌이 꽤 다를 수 있습니다Reservation, ModifyReservation 이렇게 가는 것 보다는 ReservationCancel 이런 행위가 나오는 것은 코드나 구조를 봤을 때 상당히 자연스러울 것 같습니다아무래도 전체 코드나 도메인 특징을 제가 모르다보니 임의로 질문주신 내용 기반으로 답변을 드려봤습니다!결국은 핵심은 매번 하나의 전략으로만 모두 통일할 필요는 없기 때문에 의도와 맥락과 흐름이 잘 들어가있으면 된다고 생각합니다 (어쩔땐 List 다 불러오게 했다가, 어디선 수정 클래스도 만들고) 여러모로 구현해보시고 장단점을 비교해보시고, 코드를 느껴보시고 상황에 맞춰 적절한 전략을 선택해보시는 것을 추천 드립니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

도메인 객체와 엔티티 객체 사용

안녕하세요 질문 감사드립니다!우선 여러가지 방법이 있지만 구조에 따라 선택 가능한 전략이 있을 것 같습니다!적어주신 1번의 경우 현재 강의 구조에서는 Entity가 Domain 클래스를 알 수 없습니다! 그래서 불가능한 구조입니다해당 방식을 쓰려면 domain 모듈을 추출해서 db-core->domain을 알게 해야하거나 / db-core가 core-api를 알야하는데요일단 전자는 단순히 그 지저분함을 위해 작업하는게 타당한지 + 현재 우리 프로젝트의 상황 팀의 상황 등등을 봐야한다고 생각하고 후자는 배 보다 배꼽이 더 큰 의존성 문제가 있다고 봅니다!지저분한 부분이 너무 크다고 느껴지면 현실적으로는 Mapper 클래스를 생성하거나, 각 도구 클래스에 적절하게 책임을 분산하는게 낫다고 생각합니다!(제가 자바 쓴지가 좀 오래 되긴해서 최신 JDK에서는 뭔가 유용한 기능이 있지 않을까 싶네요)추가로 질문해주신 내용에서는 저는 일반적으로 한가지 기준(도메인 객체를 쓸지 엔티티 객체를 겸용으로 쓸지)을 정합니다!회사에서는 결국 공통된 규칙이 있지 않으면 혼돈이 올 수 있기 때문에 팀과 토론 후 한가지 전략을 정해서 진행하는 편입니다개인적으로 진행하는 프로젝트의 경우는 효율(생산성, 변경용이 등) / 도메인이 내 머리속에 완벽해서 잘 만들기 쉽겠다 이런 항목들을 검토한 다음 구현 전략을 확정해서 가는 편입니다!그래서 종합적으로는 대부분 시작하는 시점에 결정하고, 기존 레거시 프로젝트라면 기존 프로젝트 이해도를 잘 분석해보고 적절한 전략을 선택합니다!만약 현재 프로젝트가 모호하다면, 그것 자체가 도메인이 정립이 잘 안되어있거나 각 도구 클래스들의 행위나 역할이나 책임이 제대로 구성되어 있지 않을 수 있습니다.만약 그것에 대해 감이 아직 없다면, 일단은 Entity 와 개념 클래스(Domain)에 대해 너무 빡빡한 규칙을 적용하지 않고 어느정도 선을 넘게하여서 관망하는 것도 좋은 방법입니다!가장 중요한건 지금 나의 프로젝트와 상황을 이해하는 것이라고 봅니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

CouponService 의존성 의문

안녕하세요 질문 감사드립니다!강의에서 언급했지만 이번 강의에서는 여러 회사를 갔을때 회사마다 구현 스타일이 다를텐데 그와 유사하게 다양한 구현 형태를 볼 수 있게 넣어두었습니다또한 강의 기준으론 팀 내부에 레이어에 대한 규칙이나 합의가 없었기 때문에 정해진 규칙이 없는 상태라고 봐주시면 좋을 것 같습니다 😃결국 여러가지 구현 형태를 보시고 어떤 구현형태가 타당한지 나는 어떻게 할것인지 생각을 많이해보셨으면 좋겠습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

상품 목록 조회 고도화 질문

안녕하세요 질문 감사드립니다![옵션 존재 시 재고 관련]상품 옵션이 존재한다면 구매 단위가 상품옵션이 되는 것 이므로 상품 옵션 단위로 재고를 구성하는게 맞을 것 같습니다!Product 는 상위의 대표 상품에 대한 의미로 사용해야할 것 같고 재고에 대해서는 몰라야할 것 같습니다별개로 조회 시에는 전략이 필요할 것 같습니다.주기적으로 배치를 돌려서 모든 옵션의 재고가 다 떨어진 상품을 목록에서 제외 시키는 방법이 있을 것 같구요준 실시간으로 하려면 매번 전체 옵션의 재고를 체크해야하는 전략이 있을 것 같습니다이런 부분은 요구사항과 서비스 특징을 참고하여 구현하면 될 것 같습니다 [프로모션 관련]제 생각에는 상품 자체의 가격을 변경하는 것은 최종적으로 UI단에서만 그렇게 처리 되면 될 것 같습니다개념적으로 할인이라는 것은 상품 입장에서는 당하는 관점이라고 생각합니다그렇기에 상품에 직접적으로 할인을 설정하는 것 보다는 할인이 별개 개념으로 존재해서 두개가 병합되는 형태가 더 좋다고 생각합니다다만 클라쪽에서 "우리 계산로직 넣기 힘들고 API 하위호환성 문제도있으니 서버에서 최종 금액 주세요" 라고 한다면 Presentation Layer에서 가격을 조합해서 내리면 된다고 생각합니다모쪼록 답이 되었길 바랍니다! 감사합니다!

표현 계층에서의 접근 지점이 다양해지는것과 이를 해결하기 위한 파사드의 도입에 대해 제미니님의 생각이 궁금합니다.

안녕하세요! 질문 감사드립니다유사한 질문에 대한 답변이 있어서 링크 전달드립니다!유사 답변2혹시 보시고 추가 질문이 있다면 주시면 감사하겠습니다!

제품상세 코드 느끼기

안녕하세요 질문 감사드립니다![질문1]제가 개념도를 활용하는 전략에서는 말씀해주신 방식으로 호출해도 괜찮습니다!격벽을 세워서 개념들의 참조를 통제하고 제어하기 위한 것이니까요! [질문2]이건 전략에 따라 다릅니다만 저는 보통 Controller (Presentation Layer)는 덜 중요하고, 개념을 나타내는 영역이 아니라고 생각합니다.그러므로 Controller 에서 Service 를 조합하는 것도 한가지 방법 중 하나라고 생각합니다! 그래서 Controller 에서 Service 여러개를 조합하는 것 자체가 격벽을 넘는 행위라고 지칭하지 않습니다결국 개념과 격벽을 그리는 이유는 비즈니스,구현 도구 영역을 적절히 지켜내고 계속 성장할 수 있도록 관심을 가지기 위한 수단이기 때문에 그쪽에 집중하는게 맞다고 생각합니다 그 외에는 별개로 Controller에서 Service 조합하는 로직은 이질적이실 수 있습니다 (사실 저도 실무에서 잘 안씁니다ㅎㅎ) 대신 그 상위에 대한 영역을 만들거나 컴포넌트를 만드는 선택을 할 수 있습니다 (Facade, WrapperService, Wrapper 등등) 그것 또한 고민거리니 한번 생각해보시면 좋을 것 같습니다! 관련해선 유사 질문이 있었어서 이 질문의 답변도 참고 부탁드립니다!모쪼록 답이 되었길 바랍니다! 감사합니다!