학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]여기에 질문 내용을 남겨주세요.질문 메뉴얼 링크 따라서 build.gradle을 설정했는데, Q파일이 보이지 않습니다.사진을 보면 우측 other 파일 밑에 querydsl이 없는데 어떻게 해야 하나요?현재 저의 build.gradle 입니다. 

킬구형 강의 특별해서 좋아~ 즐길 수 있을거 같아! 이런 강의 의도를 더 믿음있게 하기 위해서 오타 제보~ 섹션 1. SYSTEM INIT: 스프링 배치 종결의 서막 2. 배치 처리, 시스템 종결의 서막💀 Flexible.png 이미지 내 오타 ItemReader interface 를 상속하는 RedisItemWriter 는 없다. RedisItemReader 가 존재한다 

Jwt토큰 클래스에서 Keys를 사용하기 위해서 더 추가해야하는것이 있나요?

강의를 보고 궁금한 점이 생겨서 질문드립니다.강의에서 구현된 송금 프로세스를 분석해보니,출금은 정상적으로 잔고가 차감되지만 입금 시 받는 계좌의 잔고를 증가시키는 로직이 없는 것 같습니다.예를 들어:- Choreography 방식: handleDepositSuccess() 메서드에서 SagaState만 COMPLETED로 업데이트- Orchestration 방식: Transaction Service에서 deposit 기록만 생성현재와 같이 데이터베이스가 서비스별로 분리된 상황에서,입금 성공 후 받는 계좌의 잔고를 증가시키는 로직을 어떻게 구현해야 하는지 궁금합니다.제가 생각한 방법은:1. Orchestration 방식: Transaction Service의 REST 응답이 성공하면,Account Service에서 받는 계좌의 잔고를 증가시킴2. Choreography 방식: Transaction Service에서 deposit.success 이벤트를 발행하면,Account Service에서 이벤트를 consume하여 받는 계좌의 잔고를 증가시킴이 두 가지 방식으로 접근하는 것이 맞는지,아니면 다른 권장 방법이 있는지 알려주시면 감사하겠습니다.

안녕하세요 강의를 보면서 SAGA 패턴에 대해 공부하면서 궁금한 부분이 생겼습니다코레오그래피 방식으로 주문 비지니스를 구성한다고 할때 메시지 브로커를 통해서 자신의 역할만 수행한다고 하셨는데 그러면 각 서비스가 어떻게 메시지를 설계해야하는지 궁금합니다주문서비스가 주문 요청을 받으면 재고 서비스에 주문한 상품에 대한 재고 감소를 진행하고 마지막으로 결제서비스가 결제를 진행할때 결제에 대한 금액을 결제서비스가 재고 서비스의 API를 통해 상품의 가격을 조회후 결제를 진행하는것인지 아니면 재고 서비스가 재고 감소를 실행하면서 상품의 가격 정보도 같이 재고 감소 성공 메시지에 추가하여 결제서비스가 이 메시지 정보를 통해 결제를 진행하는것인지 궁금합니다

안녕하세요 선생님 해당강의를 들을때 프로젝트에대한부분이 건너띄워져서 설명되어있어 다시한번 여쭤봅니다.이전에 만든 프로젝트에 applocation.yml을 그냥 붙여넣으면 되는건가요?아니면 해당 프로젝트는 새로 생성해서만드는건가요?

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]회원 서비스 테스트 강의 5:27에 member와 findMember의 getName을 통해서 맞는지 확인을 했는데 왜 객체가 아닌 이름을 통해 비교를 하는건가요?

안녕하세요 제미니님, 유튜브부터 잘 보고 있는 수강생입니다. 항상 좋은 영상과 강의 감사합니다. 다름이 아니고 블로그에 작성해주신 글 [지속 성장 가능한 소프트웨어를 만들어가는 방법] 중 소프트웨어 레이어에 대해 언급을 해주셨는데, 해당 강의의 프로젝트가 이와 유사한 구조인 듯합니다. 질문:제미니님은 현업에 계실 때에 비즈니스 레이어(Service)에서 도구 레이어(Finder, Handler,..)를 호출하는 흐름을 어느 정도까지 강제하셨는지가 궁금합니다.팀 단위의 개발에선 컨벤션이 어느정도 정해져있는게 개발 생산성에 유리하지 않을까 하는 생각에 질문 남겨봅니다. 답변 미리 감사드립니다.🙇‍♂

찜한 목록 조회나 찜하기 등에서 궁금한 점이 생겼는데요. 찜한 목록 자체가 찜한 상품 목록일텐데 그렇다면 찜 목록 조회 시 찜한 "상품" 데이터 목록을 응답해주어야 하는게 아닌가요? 상품의 아이디만 반환해주고 클라이언트에서는 해당 상품 id 목록으로 상품 목록을 재 조회하는 등의 방식으로 설계하신건지... 궁금합니다. 또 찜하기에서는 상품이 실제 존재하는 상품인지에 대한 검증이 없는 것 같은데 이 내용은 상품의 개념이기에 표현되지 않은 것일까요? 실제 존재하는 상품에 대해서만 찜하기가 가능하다. 라는 내용또한 개념으로 작용할 수 있는 것일까요?

안녕하세요!~! 이건 주문 뿐 아니라 다양한 개념에서도 할 수 있는 질문인 것 같은데요~! OrderController 에서 요청을 처리하기 위해 어쩔 수 없이 cartService 를 알고 의존하고 있는데 (개념격벽에서는 차단), 개념간 격벽의 관점에서 OrderController는 order 에 관한 개념이 아닌 것인지 궁금합니다.Controller 단계에서 여러 Service를 조합하는 코드 스타일로 작성하셨다고 했는데, 만약 Controller 에서는 깔끔한 하나의 OrderFacade(?) 의 메서드만 호출하고 Facade 안에서 여러 서비스를 조합해 기능을 수행한다고 했을 때, 이 OrderFacade 는 Order 개념으로 치지 않는 것인지도 궁금해용.NewOrder 는 Cart 에서 cart.toNewOrder() 로 바로 만들고 있잖아요?결론적으로 Cart 가 Order 를 의존하는 방향이 되어 버리는데 혹시 Cart 가 Order 를 의존하는 것을 의도하신 것인지 궁금합니다.개념 정리 강의에서 그려주신 그림을 보면Product <-- OrderProduct <-- Cart이렇게 Product 에 Order 와 Cart 가 의존하고 있는 모습인데, 위에 제가 말씀드린 로직에서는Order <-- Cart의존 화살표도 추가해야 맞을 것 같은데 혹시 제가 잘못 이해한 것인지 궁금합니다..!추가로, Product <-- OrderProduct <-- Cart이 의존 방향을 그대로 지키려면,,cart.toProductWithQuantitys() 로 카트를 프로덕트로 변환 후에NewOrder.fromProductWithQuantitys() 로 프로덕트를 오더로 생성하는 것이 의존 방향이 깔끔하게 맞지 않나 생각이 들어용, 혹시 이건 어떻게 생각하시는지 궁금합니다.제 생각에는,, 이렇게 복잡해질 바에야 Order 에서 Product 와 함께 Cart도 같이 알고 있는 것이 좀 더 간단해지지 않을까 하네용.. (지금 코드 처럼)  현업에서 기존 짜파게티 코드 위에서 개발하다 보니,, 의존 방향에 크게 신경쓰지 않고 직관으로만 개발해왔는데요,, (from~~() , to~~() 남발..ㅎㅎ)제미니님 강의를 들으면서 안일하게 생각하고 있던 부분을 다시 한 번 생각해보게 된 것 같습니다.항상 감사해요~~

상품 목록 조회하는 부분이 지금은 응답과 테이블까지 필드가 모두 같은 형태라 간단한 것 같은데, 함께 보여줘야 할 데이터가 더 많은 경우에는 어떻게 처리하시나요?예를 들어 상품 카드위에 세일 정보가 있을 수도 있고, 해당 상품이 현재까지 팔린 갯수를 카드 위에 표시해야 할 수도 있을 것 같습니다.아래는 제가 생각해본 방안입니다.서비스 컬렉션 조회 함수에서 함께 조립단점: 단일 객체가 아닌 컬렉션이기에 데이터 매핑과 조립을 위한 로직이 굉장히 길어질 수 있다. (비즈니스 로직이 아닌 느낌), 또한 개념객체를 반환하는 것이 아닌 조립된 객체를 반환하기에 화면에 표시되어야 할 부가 데이터가 변할때마다 매번 다른 객체를 만들고 반환해주어야 한다.컨트롤러에서 각각 조회 후 조립단점: 컨트롤러에서 조회 후 조립을 한다면 ~ Service 등 부가 데이터를 조회하기 위한 함수가 있을 것이고, 이 함수 또한 반환하는 객체가 있을 것인데 그럼 이때 부가 데이터를 담고 반환하는 객체 또한 개념 객체로 생각해야 할까? (화면 구성에 따라 달라지는 데이터인데 내부 개념으로 정의해도 맞는 것일까?), 개념 객체가 아니라면, Service 레이어에 위치해도 되는 것일까?적다보니 굉장히 길어진 느낌이네요... 강사님은 어떤 생각이신지 궁금합니다!긴 글 읽어주셔셔 감사드립니다!

지금은 멀티 모듈로 프로젝트를 설정해서 common이라는 공통 모듈로 분리해도 문제가 없을 것 같은데, 정말 개발 환경이 달라지면 어떻게 진행이 되나요?예를 들어, board는 java, comment는 python으로 개발이 된다고 하면, board와 comment에 사용될 common을 팀끼리 약속을 해두고 각각 서버에 구현을 해서 사용하게 되나요?

정리된 문서도 받을 수 있을까요?

안녕하세요 강의를 토대로 프로젝트에 채팅기능을 구현중입니다.강의에서는 StompHandler 에서 CONNECT, SUBSCRIBE 인 경우만 다루는데 저는 SEND 인 경우의 코드도 작성중입니다.SEND 시 사용자 정보를SecurityContextHolder.getContext().setAuthentication(auth);이런식으로 담아서 StompController 에서 SecurityContextHolder.getContext().getAuthentication().getPrincipal()이런식으로 꺼내쓰려고 했습니다.그런데 담을 때는 잘 담았는데, 막상 StompController에서 꺼낼 때는 비어져있다고(null) 합니다. 왜 비어져있는 지 알 수 있을까요? 그러면 사용자 정보를 가져올 수 있는 방법은 없는 건가요?

안녕하세요, 강사님. Product의 상세 정보(Full Information)를 ProductSection으로 분리한 이유가 궁금합니다. 섹션3.상품상세 - 코드 느끼기 수업 중 07:50 지점에서'상품 상세 정보(Full Information 부분)를 이미지만이 아닌, HTML과 이미지의 복합으로도 구성할 수 있다고 전제하고 ProductSection을 만들었다.'고 하셨는데 '상품 상세 정보를 이미지+HTML로 구성'하는 것이 ProductSection으로 분리'한다는 결정에 어떤 영향을 준건지 모르겠습니다. 제가 생각해 본 경우는 다음과 같습니다.상품의 Full Information이 여러 이미지와 HTML 요소로 구성되니 하나의 상품에 여러 요소가 연관되는 일대다 관계를 만들기 위해 별도의 개념으로 분리시켰다.Full Information을 이미지 또는 HTML로 구성할 때 이미지인지, HTML인지 타입 정보(ProductSectionType)가 필요하니 높은 응집성을 위해 별도의 개념으로 분리시켰다. 상품 정보에 특정 속성에 대한 정보(이미지인가, HTML인가)가 속성으로 포함되는 것보다는 아예 분리하는 것이 응집성이 높지 않을까 싶습니다.위의 부분 외에 분리의 이유를 예상해보면 다음고 같은 듯 합니다.ProductSection이 상품의 본질은 아니고 '상품을 어떻게 보여줄 것인가, 어떻게 판매할까'에 관한 것상품의 생성과 함께 반드시 따라 붙어야하는 종류는 아님조회 패턴, 수정 패턴이 다름상품 정보보다는 상품 섹션이 더 자주 바뀔 것 같습니다.수업 잘 듣고있습니다.감사합니다. 

현재 수강 진도를 함께 알려주세요! "1주차 3강까지 완료" 또는 "2주차 실습 중"처럼 어디까지 들으셨는지 적어주시면 맞춤형 답변을 드릴 수 있어요구체적인 상황과 함께 질문해주세요! "AI가 안 된다"보다는 "Claude에서 이런 프롬프트를 입력했는데 이런 에러가 나와요"처럼 상세하게 적어주시면 더 정확한 답변을 드릴 수 있어요스크린샷이나 코드를 첨부해주세요. 에러 화면, 현재 진행 상황을 보여주시면 문제 해결이 10배 빨라집니다! 마크다운 코드 블록(```)을 활용하면 더 깔끔하게 정리할 수 있어요커뮤니티 검색을 먼저 해보세요. 같은 문제로 고민하신 분들이 이미 해결책을 찾았을 수도 있어요. 검색 후 못 찾으시면 언제든 새로 질문해주세요!서로 도우며 함께 성장해요. 나도 모르는 건 "저도 궁금해요!"라고 댓글 달아주시고, 아는 건 적극적으로 공유해주세요. 가르치면서 더 잘하게 됩니다바이브코딩 관련 질문은 환영, 기술 세부사항은 GPT 활용! 프롬프트 작성법, AI 도구 사용법은 여기서, 복잡한 코딩 문법은 ChatGPT에게 물어보시는 게 더 빨라요진도나 과제 관련 문의는 1:1 문의를 이용해주세요. 개인적인 학습 계획, 환불, 수강 기간 연장 등은 따로 문의해주시면 더 자세히 상담드릴게요실패 사례도 공유해주세요! "이렇게 했더니 망했어요" 같은 경험담도 다른 수강생들에게 큰 도움이 됩니다. 실패도 소중한 학습 자료예요 1-7강에서 hook을 배우고 있는데 window 환경에서 cursor를 이용해서 선생님 수업 따라가는 중에 전달자료대로 세팅을 해도 claude가 setting.json을 일고 실행한 뒤에 실행 되는 게 아니고 그냥 hook 자체가 적용이 안되는데 이 문제에 대한 해결 방법을 알려주시면 감사드리겠습니다

Pageable 인터페이스와 @PageableDefault 를 컨트롤러부터 사용하면 편하게 작업할 수 있을 것이라고 생각하고 있습니다.그런데 spring-data에서 제공하는 것들이라 컨트롤러나 애플리케이션(서비스)에서 사용하면 안 될 것 같아서 새롭게 객체를 정의해서 사용해야 하는 것인가라는 생각이 드는데요. 한편으로는 유틸느낌으로 사용해도 되지 않을까라는 생각이 들기도 합니다. 실제로 @PageableDefault 이것은 org.springframework.data.web 패키지에 들어있어서 web계층을 대상으로 만들어진 것 같구요어떤식으로 풀어나가야 할까요? 추가적으로 Http interface를 사용하기 위해 @HttpExchange을 사용할 경우 required패키지 인터페이스에 바로 붙여서 사용해도 무방한걸까요?

springboot에서 actuator 강의 다음에 마이크로미터 강의가 나왔는데 actuator 없이 micrometer를 사용할수 있나요?

안녕하세요 강의 잘 보고 있습니다! 현재 아키텍처는Controller -> Service -> Resposiotry 구조로 흐름이 이어지고 Service는 각 개념에 대한(Product, Review 등..) 조회 쿼리를 묶는 Finder, 그외 CUD 기능을 묶는 Mananger 또는 Handler ? 로 이뤄져 있습니다.이 구조는 예전에 토스 슬래시 "지속 성장 가능한 코드를 만들어가능 방법"에 대해 인상 깊게 봤는데 조회용, CUD용을 별도 컴포넌트로 관리하고 Service는 이를 핸들링 하는 파사드 패턴의 구조와 유사하게 생각했었습니다. 여기서 질문이 있는데요Product와 Review는 격벽을 두는 서로 다는 개념이지만 Product라는 1급 개념이외의 하위 개념 (섹션, 카테고리)들은 상품을 추가할 때 하나의 트랜잭션으로 묶이는 대상이라고 생각이 들었습니다. 그럼 이 경우에는 리뷰는 상품과 서로 다른 개념이기 때문에 서로를 알지 못하지만, Product의 하위 급수 개념들은 ProductService 내에서 하나의 트랜잭션으로 묶는,즉, xxxService는 동일한 개념에 속한 개념들을 하나의 트랜잭션으로 묶는 파사드의 일종이라고 생각하면 될까요? 만약 맞다면 개념과 격벽을 이해하기에 각 개념은 하나의 트랜잭션으로 묶여야하나?에 대한 고민도 개념을 구분하는 방법이 될 수 있겠구나!라는 생각이 들기도 하네요 항상 잘 보고 있습니다 감사합니다!

안녕 킬구형 나는 오랜만에 배치 복습하려고 형 강의 구매했어!일단 그냥 책 보면서 실무에서 배치를 운영을 하려니깐 고민이 있어.형 생각이 궁금해서 질문을 남겨 1. Jenkins , Spring Batch형 일단 나는 Batch를 실무에서 Jenkins 스케줄러 + Batch 이렇게 사용하고 있어. 그런데 배치 인프라에 대해서 요즘 고민이 생기는 거 같아. 나는 job enabled를 false로 설정하면서 운영하고 있는데 만약에 배치가 N개로 운영되고 있다고 가정하면 port 충돌에 대해서 고민이야 물론 parameter로 port를 넘겨줄 수 있어서 현재는 스크립트로 남는 포트를 parameter로 넘겨주면서 사용하고 있어. 간편성을 생각한다면 그냥 enabled를 true로 하고 api 형식으로 그냥 호출만 해주면 이런 복잡한 과정 없이 사용할 수 있을 거 같은데 어떻게 생각해. 2. CI/CD하나의 jar에서 여러 개의 배치가 돌아가는데 이때 CI/CD 과정에서 문제가 생길 수 있을 거 같다. 현재는 ln 심볼릭 링크로 해결을 하고 있는데 이게 적절한 방식인지? 아니면 다른 방식이 있는지 궁금해 3. JobParametersIncrementer형 Spring Batch에서 JobParametersIncrementer(RunIdIncrementer 등) 관련해서 궁금한 점이 있어 만약 업무적으로 특별한 파라미터(날짜, 키 등)가 없는 반복 배치라면이 때는 run.id와 같은 증분기 기반의 값으로 JobInstance의 고유성을 관리 하지만 업무적으로 중요한 파라미터(날짜, 키 값 등)가 있다면 이 경우에는 run.id 대신 해당 파라미터를 JobInstance의 기준으로 써야 멱등성 및 실패/재실행 제어가 더 적합하다고 생각해. 실제로 파라미터가 없는 경우에는 run.id로 멱등성을 보장하고, 파라미터가 있는 경우에는 run.id 증분기를 쓰면 오히려 동일 파라미터로 재실행/복구 등 업무상 중요 컨트롤이 어렵지 않나요? 이런 경우 run.id 증분기를 같이 쓰는 게 맞는지, 아니면 아예 쓰지 않는 게 맞는지 설계 원칙이 궁금해요.https://github.com/spring-projects/spring-batch/issues/4910https://github.com/spring-projects/spring-batch/wiki/Spring-Batch-6.0-Migration-Guide