새로 개발한다면 구현 순서

안녕하세요 질문 감사드립니다! 다시 작성하신다니 아주 멋진 훈련입니다! 👍사실 저의 경우는 이 프로젝트는 강의 예제 목적이다보니 엄청 규칙을 잡고 구현하진 않았습닌다만실제로 실무라고 생각하고 구현해본다면 개념 클래스들과 개념 컴포넌트(Reader, Appender ... etc) 들의 구조를 먼저 잡고 세부 구현을 채워나가는 것을 선호합니다추가로 그 구조를 잡을때 테스트 먼저 시작하는 것을 보통 선호합니다 😃다만! 한가지 규칙과 패턴으로 구현하지 않는게 좋은 훈련 같습니다 (실제로 실무에서 저도 그렇게하구요!)요구사항 케이스마다 데이터베이스 먼저 구조를 잡는게 중요할 때가 있는 것 같구요!또 외부 연동 먼저 구축해놓고 시작하는게 유리한 경우가 있는 것 같구요 (ex] 결제 등등)개인적으로 아주 좋은 학습법이라 생각합니다, 많이 생각하시고 많이 고민하시면서 구현하시면 좋을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

장바구니 아이템 가격 기준?

안녕하세요 질문 감사드립니다!해당 부분은 최종 수정에서 누락난 부분 같습니다! 버그네요😱 최종 프로젝트를 수정해서 올려두겠습니다!(그전에 간단한 수정이니 AI로 돌려보시는걸 추천드려요ㅎㅎ)추가 질문 주신 부분에서 보면 ProductOption이 생기면서 Product의 가격은 무의미해진게 맞습니다, 다만 '대표 가격' 의 의미로 동작한다고 봐야할 것 같습니다이런걸 활용하는 쇼핑몰을 보면 고객의 선택을 이끌기 위해 이 가격을 활용하는 것 같더라구요 (상품 목록에서 노출 하는 가격을 이 것으로 사용)그치만 이러면 상세 페이지 와서 옵션 선택 후 가격이 증가하는 것을 보고 고객이 화날 수 있으니 적절히 조절해야하는 것 같습니다 (상품가격을 가장 일반적인 옵션의 가격으로 한다던가..)옵션개념에 대해 질문 주신 것은 별도 스펙으로 구현해야할 것 같습니다 회사마다 부루는 명칭은 다르겠지만 저는 그런 것을 '다중옵션' 이라고 부르는데요!그 스펙을 구현해야할 것 같습니다, 단일 선택이 아닌 여러 옵션을 선택해서 조합하는 방식이 되겠죠지금 코드에서 한번 구현해보시는 것도 좋은 훈련일 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

인텔리제이에서 legacy 프로젝트 그레이들 인식 불가

음 IDE에서 나오는 에러 메세지를 올려주시면 같이 확인 해볼 수 있을 것 같아요!또는 GPT한테 물어보면 빨리 답을 찾으실 수도 있을 겁니다!

의존 방향에 대한 고민

안녕하세요 질문 감사드립니다!아주 멋진 고민들을 하고 계시군요! 그 과정 자체가 좋은 훈련이라고 생각합니다우선 적어주신 상황에 대해 종합적인 제 의견을 드리겠습니다Coupon과 OwnedCoupon은 개념적으로 같은 격벽안에 존재합니다정확히 보면 Coupon을 기반으로 OwnedCoupon이 만들어지는 구조를 갖고 있습니다(다만 이걸 부모 자식의 관계라 보기는 어렵다고 생각합니다)같은 격벽에 존재하는 측면에서는 서로 알고 있는 부분이 크게 문제가 되지 않을 것 같습니다물론 이 부분이 맘에 너무 걸린다하면 ownedCoupon 에 coupon 정보를 모두 다 넣어 버리면 ownedCoupon은 coupon을 몰라도 되겠지만 이러면 데이터 구조 및 요구사항을 불만족 하는 부분이 생기게 되겠죠, 다른 관점의 타협하는 측면에선 다른 형태의 쿠폰 데이터 객체(ex]CouponCondition..)를 구성 할 수도 있을 것 같습니다적어주신 수정 관점에서 말해주신 부분은 아주 타당한 관점입니다 그 측면으로 보면 OwnedCouponService에 있는게 맞죠 😃결국 어떤 시선으로 내가 보고 개념의 구조를 잡아갈 것인가? 이게 중요합니다Coupon 과 OwnedCoupon은 같은 개념 군집(격벽 안에) 있는가?Coupon 과 OwnedCoupon의 거리는 얼마나 떨어져있는가?Coupon 과 OwnedCoupon의 응집도가 서로를 알고 있는게 해가 되는가?요구사항 기준 OwnedCoupon이 Coupon을 모를 수 있는가?사용자가 쿠폰을 다운로드 한다 의 의미를 OwnedCoupon를 기준점으로 바라봐도 괜찮은가?이런 느낌의 질문들을 해보시고 어떻게 구성할지 기준을 정하시면 됩니다 😃(이미 적어주신 우려 사항들도 충분히 좋은 관점들입니다) 사실 적어주신 것 처럼 논리적으로 동작 흐름을 이해해보면 정적인 Coupon을 다운로드 하면 동적인(소유 관점) OwnedCoupon이 생성이 되는게 맞기 때문에 CouponService가 타당해 보이긴합니다만이걸 쉽게 뒤집어 보면 말장난과 같습니다 OwnedCoupon은 정적 기준 데이터인 Coupon을 통해서 생성 될 수 있다그러므로 interface 역할을 하는 CouponId 를 전달 받아서 스스로를 생성한다.이것을 쿠폰 다운로드라고 보지 않고 소유 쿠폰 생성 관점으로 보겠다라고 한다면 말이 이상하지 않습니다ㅎㅎ;; 그래서 이 강의의 목적도 그랬지만 최대한 많은 고민을 하시면서 기준을 정해보시길 바랍니다 😃결국은 우리가 선택한 것이 기준이 되기 때문에 나와 팀원이 충분히 납득 할 수 있는 방향이라면 그것이 정답에 가까운 것이라고 생각합니다또한 코드는 지속적으로 계속 가꿔가야한다 생각합니다! 그래서 너무 깊은 고민보다는 요구사항 구현을 먼저 충족 하면서 고민을 계속하고 구현 완료 후 남는 시간에 한번 더 리뷰를 해서 정리하거나, 추후 리펙토링 대상으로 가져가야 한다고 봅니다 (다만 추후 리펙토링 이 말은 현실적으로 안/못 보겠다는 것이랑 비슷해서.... 일정이 빠듯하면 어려운 문제입니다)모쪼록 답이 되었길 바랍니다! 감사합니다!

예약 변경 시 '과거 정책 기준 재계산' 요구사항에 따른 스냅샷 데이터 구조 설계 고민

안녕하세요 질문 감사드립니다!우선 현실적인 타협이 가장 우선시 되어야 할 것 같습니다, 어드민/CS가 개입한 예약의 변경의 경우 특정 상황에서 진행하는 게 일반 적일 것 같은데, 그런 요청에서도 과거 기준으로 모든 걸 돌려서 진행하려면 상당히 까다로워지고, 사이드 이펙트로 현재의 재고나 현재의 옵션에도 영향이 갈 수 있게 됩니다 (로직상 실수 가능성이 높다는 의미, 가령 delete 된 옵션을 쓰는 로직을 억지로 넣어야 한다거나)상식적인 선에서는 예약의 변경은 현재 정책을 따르는 게 맞다고 생각합니다.다만 서비스의 특성 및 고객의 니즈를 맞춰야 하는 게 중요하다면 (한 명이 거래액이 몇천만 원대라던가..)심플하게는 조건에 대한 값들도 별도 json에 저장하면 될 것 같습니다, 이 값은 어드민 예약 변경 시에만 쓰일 것이기 때문에 그 정도로 구성해도 되지 않을까 싶습니다 + 변경이 잦을 수 있는 현실 or 상황 or 서비스 특성이라면 json 자체는 괜찮은 선택이라고 봅니다저도 그런 경우에는 json을 쓰긴 합니다다만 예약 전까지 정보를 보통 json에 담고 완료된 최종 데이터는 온전한 테이블에 저장하는 편이긴 합니다만, 이건 요구사항+현실에 따라 판단해야 할 것 같습니다!실제로는 회사의 정확한 상황과 서비스 성장을 위한 니즈가 더욱 중요한 부분이니 답변 내용은 참고만 부탁드립니다!이번 강의도 수강 감사합니다!

어드민(Back-office)에서 예약 변경 시, '할인 조건 재검증(쿠폰 회수)' vs '기존 혜택 유지' 중 어떤 정책이 일반적인가요?

안녕하세요 질문 감사드립니다!사실 이건 얼마나 유저에게 편의성을 제공할 것인가?에 대한 선택적 문제라고 생각합니다그래서 "일반적"을 판단하기에는 어려울 것 같습니다 아마 CS팀이 예약의 변경을 직접 진행해야하는 상황이면 유저가 손해를 보더라도 변경을 원한다라고 하는 경우로 보이기 때문에 쿠폰 박탈의 경우도 이해할 가능성이 커 보입니다(예를들면 유선상 안내 중에 "고객님 해당 일정으로 변경하시면 쿠폰이 적용 불가하여 xxxx원을 추가 결제 해주셔야하는데 진행하시겠어요?" 이런 식으로 물어본 뒤 동의를 받고 진행하는 것 이겠죠)가령 일반적인 예약건이면 상식적으론 본인이 알아서 취소하고 재결제 할텐데 타임세일 이라 지나갔거나 특정 케이스엔 그럴 수 있죠 (그래서 보통 타임세일 상품은 취소/변경이 불가하다고 고지하긴합니다) 저는 해당 문제 때문에 쿠폰 박탈 문제를 넘어서 "추가 결제(기존 결제 금액이 모잘라서 더 결제가 필요한 경우)" 기능 까지 만들었던 적이 있는데요, 발생 빈도는 적지만 운영팀이 생각보다 요긴하게 쓰긴했습니다 🤔질문으로 가서 제 생각엔 만약 구현을 한다하면 해당 정책 기준으로 쿠폰을 박탈하는게 맞긴합니다.안 그러면 서비스가 일관 된 정책이 아니고, 어뷰징의 구멍 중 하나가 되니까요 (여기 서비스는 전화해서 좀 찡찡거리면 쿠폰 조건 깨져도 그냥 할인 유지 해준다더라~ 쿠폰 조건 되는 옵션 했다가 전화로 바꿔~ 라던가....)대신 구현과 설계 관점에서는 예약의 변경을 취소 후재 예약으로 처리하는게 훨씬 관리에 수월 할 것으로 보입니다 또한 근본적으로 이런 요청이 얼마나 잦은지 부터 데이터 기반으로 소통이 필요해보입니다이런 기능 자체가 왜 필요한건지, 이런 케이스가 얼마나 많은지 등등 추가 정보를 기획팀과 운영팀에게 들어보면 좋을 것 같습니다들어보고 만약 서비스 진화와 성장 관점에서 필요한 상황(가령 그런 요구를 하는 사람들이 충성 고객이고, 주요 고객층이라면......)에서는 이런 기능이 불가피하게 필요하겠죠 아무튼 이런 부분은 구현이 좀 귀찮고 복잡해지긴합니다만, 서비스 관점을 들어보고 타당하다면구현 레벨에서는 최대한 직관적이고 단순한 전략을 선택하시길 바랍니다 (대부분 취소 -> 재예약 이겠죠, 다만 이것도 결제한 현금이 많으면 부분취소를 해버리고 결제를 유지할 수 있겠지만, 모자르면 추가 결제가 필요해져버립니다..)모쪼록 모든 상황을 모르고 질문 내용만 보고 판단한 답변이니 참고만 부탁드립니다!결국 현실에서는 서비스의 성질, 유저층, 방향성, 기획팀 수준, 운영팀의 고생 등등 고려할게 많으니 이 부분을 파악해보시길 추천드립니다!감사합니다!

선생님

두 강의 모두 들어주셔서 감사합니다!두 강의 모두 결국 수강생분들이 생각을 많이 하시고 정답보다는 뉘앙스와 느낌을 느끼면서 스스로 생각하게 만드는 게 목적이다 보니 '느낀다'라는 표현을 많이 쓰게 되는 것 같네요 😄요즘 시대에 많은 분들이 딱 정해진 답을 원하는 시대이지만 그럴수록 스스로 생각하는 게 핵심이자 능력이 될 거라고 믿어 의심치 않습니다!모쪼록 강의 잘 봐주시고 질문도 많이 부탁드립니다! 감사합니다!

OrderKeyGenerator 인스턴스화 generate() 질문

안녕하세요 질문 감사드립니다!절대 사소하지 않고 아주 중요한 부분입니다! 좋은 질문 감사드려요!저는 일반적으로 대부분 static으로 구성하지 않는편 이긴합니다이는 기본적으로 테스트 구성 시 mocking이 불편하기 때문인데요 (mocking이 안 되는 것은 아님)그 외에 기준은 개념적인 중요도와 의도를 나타내는 것을 중요하게 생각합니다그런 측면에서 OrderKey는 단순하게 Key를 생성하는 역할을 하고 있지만 이것의 의미가 중요한 부분이라 생각하고, 이 컴포넌트가 있다는 것의 의도를 나타내고 싶었기 때문에 빈으로 구성했다라고 봐주시면 좋을 것 같습니다사실 우리가 코드를 볼때 클래스의 책임과 연관성을 보여주는 많은 정보들이 있는데저는 가장 쉽게 많이 먼저 보는 것이 생성자 부분이라고 생각합니다그런 측면에서 OrderKeyGenerator 를 빈으로 구성해서 굳이굳이 주입을 받으려 한 것은Order를 생성하는 플로우에서 OrderKey를 만드는 부분을 강조하고 싶었던 의도도 있습니다ㅎㅎ 이건 어디까지나 제 생각과 기준이다보니 참고만해보시면 좋을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

외부 API 통합 시 데이터 제어 범위 설계 질문

안녕하세요 질문 감사드립니다!이미 질문 내용 자체에서 충분히 현재 상황 기준 장점/단점을 생각하고계시고 어느정도 합리적인 판단도 결정하실 수 있는 것 같기 때문에 제가 의견을 추가적으로 드리는게 의미가 없다고 생각합니다!핵심만 축약하면 결국 외부 업체에서 무언가 해주는 것은 기약이 없기도하고, 일이 의존적으로 되기 때문에 회사 내부 일정의 문제랑도 연관이 있다고 보여져서 합리적인 선택을 해야할 것 같습니다또 외부API가 의도 기준 불안전한 상태라면 특정 영역을 기준으로 외부를 격리하는 것을 기본으로하는게 좋은 방향성이라고 생각합니다! 옵션에 대해서도 고민하고 계신 부분이 회사 내부의 개념(도메인)의 구조를 잡는 관점의 결정이 더욱 중요하다고 생각합니다, 저의 의견 보다는 그 관점으로 고민해보시면 좋을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

PG 결제 승인 로직

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