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

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

제품상세 코드 느끼기

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

격벽의 순환 참조(?)

안녕하세요 질문 감사드립니다!상황에 따라 다르지만 어플리케이션 이벤트의 사용은 적절한 방법이 될 수 있습니다!회원 탈퇴 이벤트 발행 >> 각 개념에서 이벤트 수신 후 처리이 방식은 만약 탈퇴 후 처리가 여러 개념에 많다면 충분히 의존성을 끊고 관심사를 분리할 수 있는 전략이라고 봅니다 😃다른 전략 하나로는 인터페이스를 활용할 수 있다고 봅니다 UserWithdrawalPostProcessor 같은 인터페이스를 만들어두고, 각 개념에서 UserWithdrawalPostProcessor에 대한 구현체를 다 만들도록 한 후UserService 에선 탈퇴 처리 시 List 를 주입 받아 로직을 순회하여 돌리는 방법도 가능하다고 봅니다이렇게 되면 직접 접근하는 것 보다는 느슨한 의존(직접 아는 것은 아님)을 갖고 있기 때문에 어느정도 괜찮은 전략 중 하나라고 봅니다 😃다만 강의에서 중간에 스치듯 언급했지만, User는 전역적인 개념 수준입니다, 몇몇 개념을 제외하고 모든 것을 알고 연관되어 있죠 😀그렇다보니 사실 회원 탈퇴 구현 도구를 만들고 그 곳에서 대부분 개념에 접근해서 탈퇴처리를해도 문제가 없다고 생각합니다!이미 User를 개념도에 그려보면 그 순간 격벽간 순환 참조는 바로 보이게 됩니다 (이미 순환 참조인거죠ㅎㅎ) 그래서 결국 탈퇴 후 처리 로직의 규모를 보고 구현 전략을 정의하시면 좋을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다! 😃유튜브에서 다룰만한 주제 같아서 추후에 유튜브에서도 얘기해보겠습니다!이슈 : https://github.com/geminiKim/dev-practice/issues/151

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

안녕하세요 질문 감사드립니다![질문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 는 비즈니스 로직을 잘 나타내는 것을 목적을 하고 있습니다그외 도구 컴포넌트들은 구현을 중심으로 구성 되어있으며 재사용성이 높은 도구 역할을 한다고 생각해주시면 될 것 같습니다!그래서 특정 개념에서의 로직이 응집 되어있는 객체 라고 보시는 것은 잘 보신 것 같습니다 😃고민해보시고 추가적인 고민이 있으시다면 편하게 질문해주세요!모쪼록 답이 되었길 바랍니다! 감사합니다!