안녕하세요 토비님현재 파트1에서는 아직 required 포트에있는 repository 인터페이스를 다른 도메인에서 사용하고 있지 않아서 중복이 발생하고 있지 않지만, 만약 다른 도메인에서도 같은 리포지토리를 사용해야할 경우 어떻게 하면 좋을지 질문드립니다. 제가 생각한건 첨부한 이미지와 같습니다. 도메인별로 각각 required 포트에 MemberFinder 인터페이스를 선언하고 그것을 Adapter layer에서 각각 도메인 별로 구현합니다. 하지만 실제 로직은 Adapter레이어에 있는 MemberRepository를 부르는 역할만 할 뿐입니다 

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]강의를 들으면서 웬만하면 repository 에서 entity 를 받아와서 이걸 Dto 로 변환해서 반환하게끔 처리하는 것을 배웠습니다.다만 실무에서 연관관계 매핑을 쓰지 않을 경우 어떤 전략을 취해야 하는지 모르겠어서 질문드립니다.단일 entity 만을 반환하는 경우 크게 문제되지 않지만, join 을 하게될 경우 entity 가 2개 이상이 필요한데 이 경우 Dto 를 쓸 수밖에 없는 상황이라고 생각됩니다.(혹은 querydsl 에서 Tuple 을 쓸 수 있다고 생각합니다) 이런 경우 어떻게 repository 에서 service 로 데이터를 올려주나요?

먼저 재미있게 강의 잘보고 있습니다. 감사합니다.프로젝트에서 storage 모듈을 보다가 모든 entity가 status를 갖는다는 것을 알게되었습니다.class xxEntity():BaseEntity() // base entity가 status를 갖고 있고 // 위의 코드는 상속이라고 알고있습니다(AI로 확인해봤는데 만약 아니라면 민망할것같네요...)모든 entity가 상태가 필요한가? 하는 생각이 들어서요. 아니면 status를 기본으로 설정하면서 어떤 장점을 의도하려고 하신건지 궁금합니다.

안녕하세요 제미니님 강의를 보다 궁금한 점이 생겨 질문드립니다.리뷰 작성 시 주문아이템 건에 대해 한 건의 리뷰만 작성 가능하도록 요구사항을 잡고 작성하셨습니다.따라서 새로운 리뷰를 작성할 때 해당 상품에 대한 주문아이템 리스트를 조회하여 아직 기간 내에 작성하지 않은 주문아이템이 있을 시 작성이 가능하도록 하셨는데요.이런 경우 ReviewKey없이 바로 주문아이템 건에 대한 FK를 잡아도 될거 같은데 FK를 잡지 않고 ReviewKey를 별도로 만드신 이유가 궁금합니다 !

안녕하세요!리뷰 쪽 강의를 듣다가 궁금한 점이 있어 질문드립니다.강의에서는 findReviews를 제외하고 나머지 기능은 Implement Layer를 통해 각각 값을 전달하는 구조로 되어 있는 것 같습니다.저도 코드 응집도를 높이기 위해 비슷한 구조를 사용 할때가 있는데 실제로는 ReviewService가 여러 작은 서비스에 위임하는 퍼사드 역할을 하게 되는 경우가 있습니다.이런 퍼사드 서비스는 테스트를 어떻게 하는 것이 좋을지 고민입니다. 제가 생각하기에는,1. 통합 테스트를 통해 전체 흐름을 검증하거나2. 각 작은 서비스들을 목(Mock) 혹은 페이크로 대체하여 호출만 검증하는 방법이 가능할 것 같은데 어느 방법이 더 적합한지 확신이 없어 질문드립니다.

[질문 내용]build까지 성공했는데 해당 경로로 들어갔을 때 libs가 없네요 이런 경우에는 빌드가 제대로 되지 않은건가요?

강의를 보다보니 궁금한 점이 있어 질문 남깁니다. 첫번째로 궁금한 점은 AbstractPagingItemReader의 코드를 doRead 함수 안에서 lock을 잡고 있으며, doReadPage가 끝난 후 lock을 푸는 것을 확인할 수 있었습니다..doReadPage에 실제로 paging 로직이 존재하니 사실상 paging 로직은 직렬로 수행되는 것과 다를 바 없을 것이며, 성능적으로 크게 증가하지 않을 것 같다는 생각이 드는데요.. (거의 직렬 처리와 유사할 것 같다는 생각이 드네요..) 사실상 병렬 처리라해도 Reader쪽에서 성능 향상이 거의 없다고 보면 될까요? 두번째로 궁금한 점은 AbstractPagingItemReader 상위 클래스인 AbstractItemCountingItemStreamItemReader의 read 함수를 보니 멤버 변수인 currentItemCount를 증가시키는 로직이 존재하더라구요..  이 부분도 병렬처리에 문제가 될 것 같다는 생각이 들고 해당 클래스의 주석에도 "Subclasses are inherently <b>not</b> thread-safe." 라고 적혀있는 것으로 봐서는 문제가 존재하는 것 같은데요.. 그럼에도 불구하고 기능상 영향이 없으니 하위 클래스인 AbstractPagingItemReader는 thread-safe하다고 나와있는 것이라고 생각하면될까요??

안녕하세요. 섹션 2까지 수강한 뒤, 몇 가지 궁금한 점이 있어 질문드립니다. 1. 섹션 1 상황 정의 관련섹션 1 상황 정의에서 다음 이미지와 같이 상황을 정의했습니다.   이러한 초기 시스템과 비즈니스 상황을 가정할 때, 다음 두 가지 사항이 궁금합니다.서버 스펙: 현재 두 대의 서비스 서버에 대해 강의에서 가정한 하드웨어 스펙(CPU 코어 수, 메모리 용량 등)은 어느 정도일까요?인프라 예상 투자 비용: 초기 시스템 구성(서버, DB, 로드 밸런서 등)을 위해 현실적으로 투자 가능하다고 설정한 예상 비용 규모는 어느 정도였는지 궁금합니다. 2. 섹션 2 상품과 카테고리 개념도 관련섹션 2에서 다루신 상품과 카테고리 개념도에서 ProductCategory를 Product의 하위 개념으로 이해했습니다. 이 경우, Category와의 의존성만 끊고, 객체를 직접 참조하도록 설계하는 것이 더 직관적일 수도 있을 것 같다는 생각이 들었습니다. 혹시 실제 설계에서는 ProductCategory 엔티티가 Product 엔티티를 직접 참조하는 대신, productId만을 참조하도록 설계하신 이유나 의도가 있을까요?또한, 일반적으로 엔티티 간의 관계를 설계할 때, 객체를 직접 참조할지 아니면 식별자(ID)만을 참조할지를 어떤 기준으로 판단하시는지도 궁금합니다. 좋은 강의 제공해주셔서 감사합니다. 남은 강의도 열심히 수강하겠습니다!

  말씀해주신 부분에서 Product 객체 응집도를 높이기 위해 서로 Review 객체를 모르는 것이 좋다고 말씀 해주셨는데요. 그럼 코드 내용을 보면 Controller 객체에 Product 객체 하고 Review 객체를 알고 있다는 것 인데요.만약 요구 사항이 Product 데이터 하고 Review 데이터를 가공해서 계산된 데이터를 Client 에게 내려줘야 하는 상황이 있다고 가정 하겠습니다. 그럼 Controller 객체에는 Product 데이터 하고 Review 데이터를 가공해서 계산 하는 비지니스 로직이 분명 있을 것 같습니다. 이것을 Controller 객체에 비지니스 로직이 있으면 Controller 에 대한 역할이 더 분담 되는 것 같아서요. 그래서 제가 생각 한 것은 ProductReview 객체를 만들어서 (어떻게 보면 퍼사드 패턴 이겠네요...)ProductReview 객체가 Product 하고 Review 객체를 알고 Product 하고 Review 객체는 서로 모르는 것이 좋지 않을까 생각 됩니다. 이 방법은 어떻게 생각하시는 궁금 합니다. 굳이 Product 하고 Review 로 대표적으로 설명 해주셨는데 보통 실전에서는 이와 같은 비슷한 상황이 많이 발생 될 것 같습니다.    

안녕하세요 제미니님코드를 보다가 core-enum 모듈에 대해 궁금점이 생겨 질문드립니다.core-enum의 경우 core-api와 db-core에서 의존성을 받아 쓰고 있는데요.core-api가 db-core를 의존성 받아 사용하고 있고 core-enum에 있는 값들은 모두 db-core에서 사용하고 있습니다. 이런 경우 그냥 db-core에 enum 값들이 있어도 될거 같은데 굳이 따로 모듈로 빼신 이유가 궁금합니다 !최대한 생각해본 바로는 db-core를 사용하지 않는 또 다른 모듈에서 사용한다는 가정 밖에 떠오르지 않습니다.혹시 다른 이유가 있을까요?

공부한 내용을 블로그에 정리하려 하는데, 혹시 예제 사용해도 괜찮을까요?

안녕하세요COUNT 쿼리에 LIMIT 를 지정하는 이유가 있을까요? 설명해주셨는데 놓친건지 모르겠네요ㅜ

Discord 임계값 알림 시스템 구축 부분 노션에 작성된 것이 없는 것같아 질문드립니다

제미니님 안녕하세요 !강의 수강 중 Product와 Category간 개념 정리네 대해 질문이 있습니다 ! 강의를 들으면서 Product와 Category에서 Product가 상위의 개념이라고 선택하시고 매핑 테이블을 네이밍을 ProductCategory을 사용하셨다고 이해하고있습니다 !그런데 개념도를 봤을때.. 개념 간 매핑해주는 ProductCategory가 Product 개념 영역에 있는게 맞는지 의문이 들었습니다 ! Category가 Product 하위의 부가적인 정보로서 ProductCategory가 Product 개념 영역에 존재할 수도 있지만.. 강의에서 설계하는데 있어 Product가 상위 개념으로 판단을 했고, ProductCategory는 Category에 대한 부가정보인데 상위 개념이 하위 개념에 대한 것을 모르도록하는게 맞지 않나 라는 생각이 들어서 질문드립니다 !

안녕하세요! 평범한 대학생 백엔드 개발자 입니다!저희 대학생에게 맞는 강의 영상 찍어주셔서 감사합니다 :) 다름이 아니라 도메인 계층에서 Page를 사용해도 되는지 의문이 발생했습니다.제가 인지한바로는 도메인 계층은 순수한 로직이 이루어져야한다고 알고 있습니다.그래서 저는 도메인 계층에서 Page에 관한 DTO를 하나 생성하고 스토리지 모듈에서 해당 DTO로 반환하게 코드를 작성하였습니다.  그런데 강사님의 코드를 보니까 도메인 계층에서 Page를 사용하고 있더라고요... 단순한 트레이드 오프일까요? 클린 아키텍처와 회사 내 규칙을 따를 것이냐 아니면 개발 편의성을 위해 Page만 허락한다는 등... 그런 것들이 존재할까요? 그렇지만 도메인 계층에서 스프링 프레임워크에 대한 의존성을 갖는게 되지 않을까요... 잘 모르겠습니다! 이렇게 생각하는게 좋은 방향일까요? ㅠㅠ(추가로 도메인 계층에서 Page를 사용할 시 테스트 코드는 어떻게 작성하나요?)

1주차 hooks 강의 듣고 있는데, commit 전에 review를 하도록 하고 싶은데 실제로 해보니 되긴 되는데 좀 오락가락 해서요. 혹시 hooks matcher가 한정되어 있을까요? commit은 좀 의도랑 다르게 접근한거지 궁금하네요

안녕하세요 토비님. 강의 잘 수강하고 있습니다.아직 강의 초반부만 들었지만, 아주 감명깊게 수강중입니다.혹시 다음강의 오픈은 언제쯤 예상하고 계실까요?

안녕하세요 카프카 관련하여 질문드립니다.카프카로 DB Insert 요청을 비동기 처리할 경우 트래픽이 급증하면 데이터베이스가 감당할 수 있는 QPS를 초과하여 과부하가 발생할 수 있습니다. 실무에서는 이러한 상황을 어떻게 대응하는지 궁금합니다.감사합니다.

컨틀롤러 단에서 데이터가 유실되는것 같습니다.

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.안녕하세요 선생님!지난번에 남겨주신 답변내용을 보면서 전략도입의 배경부터 처리과정까지 복기해보았습니다.그러다가 의문이 생긴 점이 있습니다.1) 의문점Request Collapsing, 캐싱중복적재를 제외하고 캐싱하여 데이터를 추출하는 과정만을 보았을때, 원본과 캐싱 데이터 모두 Redis에서 추출해오는 것인데, 원본추출과 비교하였을때 과정적으로 어떠한 차이점이 추가적으로 있있기에 별도의 과정으로 간주하는 것일까? 즉, "캐싱하여 가지고 오는 과정"과 "원본 데이터 추출"을 따로 보고 계셨기에, 어떠한 차이점이 있는지 의문점이 들었습니다. 2) 의문점이 생긴 이유단순하게 간략히 말씀드리자면,조회수 원본데이터는 Redis에서 가져오는 조회수이고, 캐싱해서 가져오는 것 역시 Redis에서 가져오는 조회수로 보여집니다. 원본데이터가 MySQL과 같은 디스크 조회 비용이 큰 저장소에 들어있는 것이 아니라, 동일한 In Memory database인 Redis에서 가져오는 것이기에 성능/비용적으로 캐싱 데이터를 가지고 오는 것에 큰 이점을 느끼지 못하였습니다. 세부적으로 살펴보았을때,ViewClient에서 원본 데이터를 가지고 오는 경우 아래 로직을 통해 Redis에서 추출합니다.articleViewCountRepository.read(articleId);이떄 key는 view::article::#articleId::view_count 입니다.ViewClient에서 Aspect를 처리하여 캐싱 데이터를 가지고 오는 경우 Redis에서 추출합니다.이때 key는 articleViewCount::#articleId입니다.이 과정에 대해 캐싱을 하는 목적을 생각해보았을때(=원본데이터 추출에 시간이 오래 걸릴 경우 성능이 빠른 다른 데이터저장소를 운용하여 이곳에서 데이터를 추출해오기 위함), 동일하게 Redis에서 추출하는 데이터임에에도 key를 별도로 운용하고, 데이터를 추출하는 과정도 다르게 가져가는(간주하는) 이유가 무엇인지 궁금하여 문의코자 합니다(물론 전체 로직을 살펴보았을때는 기존 대비 중복적재/Request Collapsing 과정을 추가하였기에 당연히 성능적인 이점이 존재하겠지만, 데이터를 가져오는 과정 그 자체만을 보았을때는 의문점이 들었습니다). 이게 데이터를 추출하는 과정이 다르기에, 동일한 key로 운용하면 실무적으로 로직이나 key관리방안이 복잡해져서 관리의 효율화를 위해 나누는 것일까요(즉, 기존과 달리 분산락도 사용하고 중복적재를 방지하기 위해 이용하므로 목적 자체가 다르기에 key 포맷 및 캐싱을 별도로 운용하는 것으로 이해하는 것이 적절한지)? 제가 캐싱의 목적 부터 잘못 이해하고 있는 것일 수 있고, 실무적으로 비용/성능적 유리하다는 의미가 무엇인지 잘못 이해하고 있는 것일 수 있다고 생각하고 있습니다. 그렇기에 챗지피티에게 물어보기보다는 실무적으로 경험이 풍부하시고 그만큼 검증된 선생님의 판단이 더 정확하고 궁금하여 질문드리게 되었습니다. 바쁘신데도 항상 성심성의껏 답변해주시는 선생님께 감사의 말씀 드립니다. 이효균 드림.