결제 관련 서킷 브레이커 전략, 데이터 정합성 및 타임아웃 설정 질문

안녕하세요 질문 감사드립니다![질문1-1]해당 방식의 보정 배치는 규모에 따라다르지만 기본적으로 유효하다고 봅니다!문제 상황을 예로 들면 READY 상태로 배치를 돌리기 때문에 만약 서비스 특정이나, 어떤 이벤트로 고객들이 결제창까지 갔다가 결제를 안하고 서비스를 꺼버리게 되면 데이터가 모두 READY 일텐데 그럼 이 결제건들에 대해서는 무한으로 PG사에 조회를 하는 방식일 것이고데이터가 많기 때문에 배치가 점점 느려질 것 입니다 (조회 기간도 만들긴 하겠지만 미결제건이 폭등할때 기준으로 보면 많을 수 있겠죠)이 부분은 내부 배치도 문제지만 PG사 쪽에서도 건별 요청이 계속 들어올 것이기 때문에 비정상적인 조회로 볼 수 있을 것 같습니다그래서 이걸 대체하려면 다른 전략을 활용 할 수 있을 것 같습니다Payment 의 결제 중 같은 상태를 추가하거나, 별도 테이블에 실패 이력을 쌓거나 (물론 이것도 우리 디비 장애면 안쌓일텐데, 이건 운영 이슈로 해결해야겠죠 ㅎㅎ)또는 이벤트 적재 인프라가 있다면 결제 실패시 이벤트를 발행해서 맥락을 끊어서 볼수도 있을 것 같습니다[질문2-1]적어주신 내용도 타임아웃들을 짧게 잡는 것과 연관이 있습니다!일반적으로 배치나 특이사항을 제외하고는 커넥션 타임아웃은 1초도 넉넉하다고 봅니다정상적인 상황에서 서버와 디비가 같은 네트웍을 사용하게 구성하는게 일반적이고, 그럼 연결을 얻는데는 초 단위일 필요도 없기 때문에 최소한으로 잡아둔 것입니다!다만 소켓타임아웃은 쿼리의 규모, 데이터의 양에 따라도 문제가 생길 수 있는데요, 일반적으로 배치를 제외하고는 그런 쿼리를 만들지 않는게 좋기 때문에 저는 처음부터 길게 주지 않는 편입니다! (추후 정말 필요하면 늘리는 방식)[질문2-2]음.. 이건 사실 매 상황마다 다르기 때문에 어떤 기준은 없는 것 같습니다!대신 쓸대없이 시간을 낭비하지 않게 구성하는게 기본 자세인 것 같습니다시간을 늘려야한다면 충분히 타당한 근거가 있어야한다고 봅니다저도 어디서 들은건데 현대의 대한민국 유저들은 화면이 2.5초만 멈춰있어도 바로 인지를 하고 더 나아가서는 답답함을 느끼기 시작한다고 합니다(대신 결제나 공공기관 사이트 등 몇몇 부분에선 느린 것에 학습이 아주 잘 되어있죠, 기대가 없달까요)반대로 에러가 뜨고 “다시 시도해주세요” 는 적어도 한두번 정도는 짜증을 안 낸다고 하네요(썻던 글이 다 날라가는게 아니라면..)그래서 결국 가능한+현실적인 타협선을 잘 정해서 전체 대기 시간을 조절하는게 좋다고 생각합니다또 우리 서버와 디비 등 내부 통제가능한 인프라에 대해서는 가능한 짧게 잡아주는게 좋다고 생각합니다, 일반적으로 같은 네트워크 망이면 느슨하게 설정할 필요가 없겠죠!각각 답변이 잘 됬나 모르겠네요! 추가 질문은 답글이나 질문으로 올려주시길 바랍니다!모쪼록 답이 됬길 바랍니다! 감사합니다!

비회원 개념 추가 시 개선 방향

안녕하세요 질문 감사드립니다!비회원에 대한 방식은 적어주신 것 처럼 여러가지 방식이 있을 것 같습니다그럼 방식은 여러가지고 뭐로 해도 될 것 같은데요! 제가 의견을 드리기전에 wheon06님은 어떤 방식으로 처리하실 것 같으신가요?그리고 왜 그 방식/전략을 써야한다고 생각하실지 궁금합니다!먼저 제 의견을 한가지만 드리면 비회원의 주문,결제 까지 요구사항이 있다면 저는 비회원은 개념이 아니라고 볼 것 같습니다!고민해보시고 의견 답글로 남겨주시면 저도 제 의견을 말씀드리겠습니다!

DB 레이어 잘 다루는 법

안녕하세요 질문 감사드립니다!포인트 적립 트랜잭션유사 질문이 있어서 해당 답변 참고 부탁드립니다!https://inf.run/3z6MS 낙관적락 예외 처리예외처리는 상황에 따라 전략을 결정하기 나름이라고 봅니다! Advice 레벨에서 정의할 수도 있고, 한번 더 예외를 감쌀수도 있고, 예외를 아예 먹고 에러 로그를 남기고 지나갈 수도 있죠!상황에 맞춰어서 적절한 구현을 하는게 맞다고 생각합니다! 해당 강의에서는 낙관적락에 대한 부분이 핵심이 아니다보니 Advice 에서 공통 에러로 처리하고, 내부 로그를 통해 추적해서 처리하는 식이라고 이해해주셔도 될 것 같습니다!이것 또한 요구사항과 고객한테 에러를 얼마나 친절하게 알려줄 것인지에 대한 관점으로 생각해보면 좋다고 봅니다! Repository, JpaRepository 분리프로젝트의 구조 자체는 상황을 적절히 잘 봐야합니다! 해당 강의에서 상황 설명을 드렸지만상당히 소규모 팀이고, 요구사항은 매일 변칙적으로 변하고 좀 더 효율적이고 기민하게 작업 할 수 있는 구조를 채택했다고 봐주시면 될 것 같습니다!저는 실무에서도 가능한 작고 심플한 구조를 통해서 서비스를 성장시키는 것을 선호합니다특히 도메인의 진짜 정체에 대해서 잘 모르는 상황에서는 이 구조가 오히려 자유도와 유연함을 통한 이점을 얻기 좋았던 것 같습니다!쩌스트 예제의 경우는 제가 도메인을 온전히 알고있고, 단독 프로젝트기 때문에 강제성을 더 올리기 위해 해당 구조를 썻었습니다! 😃 Repository 가 분리된 경우에서의 검증, 업데이트 로직적어주신 코드 자체도 가능한 스타일 이라고 봅니다! 이런 부분이 사실 팀 내 협의가 하나하나 쌓여있어야하는 부분이겠죠 😃만약 제가 같은 팀이라고 가정하고 해당 코드에 대해 표준을 잡는데 의견을 드린다면비즈니스 레이어로 정의한 곳에 너무 디테일한 로직의 모습이 나와있는 것 같아서 행위 단위로 도구를 만들어 응집도를 올리면 어떨까요?라고 말씀드려 볼 것 같습니다 현재 강의 예제 코드도 리뷰 작성 후 7일 후 업데이트 할수 없는 기준으로 작성 되어있어서 참고해보시면 될 것 같습니다!위의 말씀드렸지만 제 경우는 프로젝트 구조를 1개로 가져가지 않습니다자주 말하지만 소프트웨어는 살아있는 유기체와 같기 때문에 그에 맞춰서 환경을 조성하고 성장 시켜야한다고 생각합니다 😀그런 측면에서 결국 아직 개발의 주도권이 사람에게 있기 때문에 우리가 처한 상황, 비즈니스의 흐름, 일의 속도, 팀의 구성원, 팀의 역량 등등을 고려해서 적절한 프로젝트 구조 를 잡는게 중요하다고 생각합니다!너무 비대하고 구현에 절차가 많고, 도메인을 잘 모르는데 오염이 되기 쉽거나, 오버엔지니어링 하기 쉬운 구조 등등 이런 것들을 언제 쓰는게 좋은지반대로 어떤 상황에서 가볍고 변경이 쉬운 구조를 가야하는지결국 일을 잘 돌아가게하고, 우리 소프트웨어가 효율적으로 커갈 수 있는 구조를 잡는게 더 중요한 것 같습니다!질문이 많아서 제가 모두 다 제대로 답변했는지 모르겠네요! 😅이해가 안가시거나, 추가 질문 있다면 편하게 주시길 바랍니다! 유튜브 시청도 감사합니다!모쪼록 답이 되었길 바랍니다! 완강 후 수강평도 기대하겠습니다!

엔티티 연관관계 사용

안녕하세요 질문 감사드립니다!우선 핵심만 말하면 저는 실무에서도 생명주기 가 같지 않으면 연관관계를 걸지 않습니다또한 양방향 관계는 걸지않고, 가급적 OneToMany는 정말 필요한 상황이 아니면 사용하지 않습니다지금 예제로 보면 Order -> OrderItem 은 관계를 맺지 않고 OrderItem -> Order 정도는 걸 수 있다고 보긴합니다!이는 결국 "Order 가 OrderItem 을 필수로 알아야하는가?" 가 핵심입니다 단순히 생성 관점으로만 보지 않고 조회 패턴 (Order 조회 시 OrderItem 을 항상 가져와야하는가? Lazy 로 걸면 되지만, 그럼에도 관계가 있어야하는 이유가 무엇일까? 등의 고민)그래서 저는 가급적 관계 보다는 조합을 선호하고 추후에 필요 시 관계를 지정하는 편입니다(사실 관계를 걸었다가 푸는 것 보다, 안 걸고 키로 조합하다가 거는게 수정이 쉽고, 사이드이펙트가 적은편입니다)이건 일반적으로 제가 사용하는 전략이라 적어주신 것 처럼 팀 컨벤션을 정하는게 좋습니다, 다만 단순히 생성 관점에서만으로 접근하는 것은 좀 더 생각해봐야하는 부분 같습니다 OrderItemRepository는 분명히 다른 구현 때문에라도 어짜피 생길 것 이기 떄문입니다(꾸역꾸역 안 만들겠다면 정산 로직에서 OrderItem 단위 정산을 할때 Order 를 조회해서 분류하거나 OrderRepository에 조금 과한 쿼리가 다 들어가야겠죠)추가적으로 주신 질문은 잘 생각해보면 상품과 재고를 같은 관점으로 볼 것인가를 고민해보면 좋을 것 같습니다정확히 보면 재고는 상품과 직접 연관이 있어야하는가?에 대한 고민을 해볼 수 있을 것 같습니다, 타협할 수 있는 전략으로는 ProductStockXXX 같은 친구를 만들어서 해당 역할을 맡길 수 있을 것 같습니다.추가로 더 고민해보실 거리를 드리면 정확히하면 재고는 주문 보단 "결제/취소"하고 상당히 가깝습니다가령 주문 생성시 재고를 차감한다면 복원은 언제해야할까요?, 그리고 주문 생성하고 사이트를 끄거나 하는 사람의 재고는 어떻게 처리해야할까요?등등 관점으로 한번 더 생각해보시면 좋을 것 같습니다!연관관계 관련 주제에 대한 제 유튜브 영상도 링크드리오니 궁금하시면 한번 보시길 바랍니다!https://www.youtube.com/watch?v=vgNHW_nb2mghttps://www.youtube.com/watch?v=j9bcvidVQgghttps://www.youtube.com/watch?v=VGp1g9irQRI모쪼록 답이 되었길 바랍니다! 감사합니다!완강까지 잘 부탁드리고 수강평도 기대하겠습니다! 추가 질문이 있다면 편하게 주세요!

엔티티 상태를 조회하는 시점

안녕하세요! 질문 감사드립니다!적어주신 내용과 유사합니다! 단건 조회시에는 코드 기반으로 조회하는게 가능하다고 생각합니다(추가로 ID기반 조회라면 사실 status를 쿼리에 직접 넣어도 조회 데이터 범위가 명확하기 때문에 성능에도 영향이 없습니다)대부분 목록 조회 시에는 직접 쿼리에 질의하는게 맞다고 생각합니다 (페이징 처리가 있다면 더더욱 그래야겠죠)다만 상태 때문에 불 필요한 인덱스가 추가되어야하는지, 현재 인덱스의 효율이 괜찮은지 등의 구성을 보고 판단하는게 중요하다고 생각합니다!추가로 softDelete의 경우 개인적으로는 직관적이고 예측가능하고 누구나 이해하기 쉬우면서 코드 기반으로 테스트하기 더 쉬운 구조를 선호하다보니, 어노테이션 기반을 그렇게 선호하진 않아서 저는 불호에 가깝습니다! 😅그치만 적절히 검토해서 사용해도 무방하다고 생각합니다!모쪼록 답이 되었길 바랍니다! 감사합니다!완강까지 화이팅 해주시고, 완강 후 후기도 기대하겠습니다!

섹션3. 상품 상세. 코드느끼기 12:47 질문.

안녕하세요 질문 감사드립니다!우선 질문의 내용이 조금 헷갈립니다 ProductFinder -> ProductUsecase or ProductUsecase정의한 곳에 Product 서비스 와 ProductSection 서비스를 갖고 안에서 작업을 해보는건 어떻게 생각하실까요?이게 어떤 구조를 말씀하시는 것 인지 모호하네요!ProductProductSecion 명명이 어떤 배경에서 나오는지도 추가 설명해주시면 좋을 것 같습니다! 🤔그리고 뒤에 적어주신 UseCase를 만들어서 ProductUseCase 로 정의하고 ProductService, ProductSectionService 를 주입받아 사용하게 하는 구조를 말하신 것이면, 이것 자체를 규칙으로 정의한다면 나쁘지 않아 보입니다, (다만 개인적으로 UseCase 라는 명명을 좋아하진 않는 것 같습니다!, Product 와 ProductSection 두개 가져오는게 같은 개념안에서 UseCase라고 정의하기엔 다소 아쉽다고 생각합니다)Delegator를 만들어서 구현하는 방법은 지금 상황에서 굳이라는 생각이 들긴합니다!그 정도의 코드 규모가 아니라는 생각입니다!질문이 다소 정보가 적고 추상적이라 적절히 답을 했는지 저도 모르겠네요! 관련하여 상세한 내용이나 예시 코드를 적어주셔도 좋을 것 같습니다!관련해서 추가적인 질문이나 설명은 답글 주시길 바랍니다! 감사합니다!

xxx서비스와 xxx핸들러 의 구분 기준

안녕하세요 질문 감사드립니다!먼저 해당 강의는 여러가지 구현 패턴을 보여주면서 수강생 분들이 최대한 생각을 많이 하시도록 구성하였습니다!그렇기 때문에 구현 패턴이 다양하여서(어떤 코드는 Service 에 Repository 접근과 로직이 다 있음) 그 다양성 자체를 느껴주시면 좋을 것 같습니다!그럼에도 질문의 기준 관련해서 힌트와 생각할 거리를 드리면 Service 와 도구(컴포넌트)들을 나눠놓은 구현 패턴에 대해서는 과거 제 글 중 하나인 지속 성장 가능한 소프트웨어를 만들어가는 방법을 기반으로 작성되었습니다 (인프런에 동명의 무료 강의도 있습니다)해당 글 참고하시면 어느정도 이해가 되실 것 같습니다!간단히 설명드리면 *Service 는 비즈니스 로직을 잘 나타내는 것을 목적을 하고 있습니다그외 도구 컴포넌트들은 구현을 중심으로 구성 되어있으며 재사용성이 높은 도구 역할을 한다고 생각해주시면 될 것 같습니다!그래서 특정 개념에서의 로직이 응집 되어있는 객체 라고 보시는 것은 잘 보신 것 같습니다 😃고민해보시고 추가적인 고민이 있으시다면 편하게 질문해주세요!모쪼록 답이 되었길 바랍니다! 감사합니다!

상품 전체보기가 없습니다. 카테고리는 필수로 선택해야 합니다.

안녕하세요 질문 감사드립니다핵심은 어디를 중심으로 잡을 것인가? 어떤 것에 비중을 더 줄것인가? 우리 비즈니스에선 어떤 선택이 맞을까? 에 대한 결정이라고 생각하기 때문에 CategoryProduct 라고 표현하는 것도 선택가능한 전략 중 충분히 괜찮고 가능하다고 생각합니다!대신 Category 가 그만큼 현재 서비스의 형태와 비즈니스 로직 구조에서 중요한 역할을 하고 있다면 더더욱 타당한 전략이라고 생각 될 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

@Transactional에 관해서 질문드립니다.

안녕하세요! 질문 감사드립니다 😃이 부분은 의도적으로 Transaction 을 걸지 않은 게 맞습니다! (고민해보시라고 의도한 바인데 고민을 하고 계시다니 아주 좋네요!)트랜잭션을 잠시 떠나서 다른 관점으로 생각해보면 "Review 작성 후 Point 작성이 실패했다해서, 반드시 Review가 롤백이 되어야하나?, 이게 고객이 심각한 문제를 겪는 것일까?" 를 생각해볼 수 있을 것 같습니다물론 이것 또한 상황마다 다르기 때문에 반드시! 포인트는 완벽히 그 순간에 100% 지급되야해! 라는 비즈니스적 요구사항과 니즈가 있다면 묶어주는게 맞다고 생각합니다결국 리뷰 작성 시 포인트가 지급이 안되는 문제가 얼마나 빈번하게 발생 하는지, 그것이 얼마나 중요한 사항인지에 따라 선택하면 되는 부분이라고 봐주시고다양한 관점으로 생각해보시면서 고민해보시면서 느껴보시면 좋을 것 같습니다! 😃 다만 지금 구조에서는 문제가 생긴다면 포인트 적립에 대한 재적립을 수동으로 해줘야합니다, 이건 운영 리소스를 쓰겠다는 것 이기 때문에 이 관점으로 우리는 운영 리소스가 적기 때문에 트랜잭션을 걸어야한다! 라는 주장도 아주 합리적이라고 생각합니다 (지급 실패 재시도를 만들면 되지 않나? 라는 의견이 나올 수도 있겠죠!)이런 관점들을 계속 느끼시면서 Point개념이 얼마나 타 개념에 응집되고 결합될것인가?에 대한 고민도 같이 해봐주시면 강의를 100% 즐기실 수 있다고 봅니다! 😀+추가적으로 조금 기능을 발전 시켜간다면 Point 적립 자체는 @Async로 처리하도록 만들 수 있을 것 같습니다 😃 이 관점도 생각해보시면 좋을 것 같습니다!모쪼록 답이 되었길 바랍니다! 추가 질문은 편하게 부탁드립니다!완강까지 잘 부탁드리고 수강평도 기대하겠습니다!

'개념과 격벽' 을 실제 업무에 어떻게 사용하면 좋을까요?

안녕하세요! 질문 감사드립니다!이번 강의는 커머스 도메인를 토대로 개념과 격벽에 대해서 충분히 느껴볼 수 있도록 제작 되었습니다ㅎㅎ (개념 느끼기 부분이 특히 그 부분을 강조해두었구요!)그래서 강의를 완강하시면 개념과 격벽을 어떻게 실무에서 활용 할 수 있을지 느껴 보실 수 있을 것 이라고 생각합니다!적어주신 것들에 대해서 제가 개념과 격벽을 활용하는 전략을 기준으로 의견드리면(제가 개념과 격벽을 언급했으니,,! 제 전략이 답에 가깝겠지만 또 무조건 답은 아니라는 점 참고해주세요ㅎㅎ 사용하기 나름이라고 봅니다)일단 적어주신 순서 대로 활용하는 것은 아닙니다!적어주신것의 순서를해 볼 수있을까~ 싶은데 애매하네요 대략 제가 재구성 해보겠습니다(사실 모든 상황에서 한가지 전략으로 활용할 순 없습니다, 회사의 상황, 규모, 기획팀 역량, 존재유무 등등 너무 고려할게 많습니다, 일반적이라고 가정하고 보편화 시켜서 적어보겠습니다)현재 전달 받은 요구사항을 분석하고 이해한 뒤 구현을 먼저 진행한다잘 못 된 요구사항, 변경 되는 요구사항, 만들다 보니 모호한 부분이 분명히 있을텐데 일정 내에서 이것도 수용하며 구현을 진행한다구현하면서 어떤 것들이 우리의 S/W의 비즈니스와 코드에서 핵심이고 중심인지 이해한다 (신규 코드라는 가정입니다, 레거시라면 레거시 현황을 이해하는것이 선행)핵심과 중심인 부분을 최대한 의존을 끊어내고 순수 할 수 있게 구현을 계속 진행한다분명히 초기에 구현 하면서 생각한 것들이 바뀔 수 있음구현이 완료되어 요구사항이 충족되어 기본적인 테스트를 성공 시킨다현재 구현 된 요구사항과 비즈니스와 코드 기준으로 개념과 격벽을 개념도에 그린다팀 내(개발,기획,+디자인) 등 공유하여 인식을 맞춘다 우선 저는 이런식으로 활용을합니다! 대부분의 신규 서비스 만들때 기준으론 초기 mvp가 나오고 나서 개념도를 최종 버전으로 그렸던 것 같아요!먼저 구현 중간중간에 개념과 격벽을 정의하면서 진행해도 되는데 일반적으로 요구사항이나 기획이 변경 될 가능성이 있으니 추후에 그리는게 좋다고 생각하긴합니다!사실 이런 순서보다 핵심은개념을 나열하고격벽을먼저 만들면 안 된다는 것 입니다그러면 결국 구현 먼저가 아니라 설계 먼저 하고 있는 것 이기 때문이라고 생각합니다 😃 (발표 후기에도 말했지만 설계 먼저 하는게 무조건 틀리다는 의견은 아닙니다ㅎㅎ)저는 여전히 구현 먼저 하는게 중요하다고 생각하는 쪽입니다.물론 코드를 구현을 하면서 생각을 계속 해야겠죠! (이 클래스를 어디서 끊을지, 누구누구를 알게 될지, 이 클래스가 개념적으로 가치가 있는지? 있다면 얼마나 중요한 개념인지,,, 등등)구현이 어느 정도 진행되고, 충분히 이해도가 생겼을때 개념을 정의하는게 좋다고 생각합니다!모쪼록 수강 감사드리고 답이 되었길 바랍니다! 강의 완강 후에도 느낌이 잘 안 느껴지시면 다시 질문주시면 좋겠습니다! 감사합니다!