안녕하세요 제미니님코드를 보다가 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 포맷 및 캐싱을 별도로 운용하는 것으로 이해하는 것이 적절한지)? 제가 캐싱의 목적 부터 잘못 이해하고 있는 것일 수 있고, 실무적으로 비용/성능적 유리하다는 의미가 무엇인지 잘못 이해하고 있는 것일 수 있다고 생각하고 있습니다. 그렇기에 챗지피티에게 물어보기보다는 실무적으로 경험이 풍부하시고 그만큼 검증된 선생님의 판단이 더 정확하고 궁금하여 질문드리게 되었습니다. 바쁘신데도 항상 성심성의껏 답변해주시는 선생님께 감사의 말씀 드립니다. 이효균 드림. 

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]여기에 질문 내용을 남겨주세요.프로젝트 지웠다가 처음부터 다시 해보기도 하고 질문글 따라 보면서 해봐도 에러가 떠서 어떻게 해야할지 모르겠어요.. .

강사님이 추구하시는 생각하는 공부에 대해서 많이 고민해보게 되었습니다.그렇다면 강사님이 생각하셨을 때, 이 강의를 보고 공부하는 이상적인 방법은 어떤게 있다고 생각하시나요?예를 들면, 하나의 섹션을 먼저 다 보고 요구 사항 정리부터 다시 시작해보기 아니면 각 강의마다 끝나고 요구사항을 정리해보고 다음 넘어가기.. 등등 강사님도 커리큘럼을 만드실 때 이런식으로 하면 좋을 것 같다가 있으셨을 것 같은데 궁금합니다.

안녕하세요.결제 부분 강의를 보니 payments API를 보면 컨트롤러에서 주문을 조회하고, 사용 할 쿠폰을 조회하고, 포인트를 조회하고, 조회 된 데이터를 PaymentService로 전달하는 스타일이더라구요. 제가 진행중인 사이드 프로젝트도 커머스가 주제입니다. 제 프로젝트도 처음에는 강의 코드 스타일대로 컨트롤러에서 필요한 데이터를 조합하고, 결제를 처리하는 Service 쪽으로 넘기는 형식이었는데, 이게 점점 결제 기능이 고도화되면서 뭔가 컨트롤러에서 비즈니스 로직의 흐름이 보이는게 맞나? 라는 생각이 들게 되었고 어느 순간부터 웬만한 Controller에서는 1개의 xxxService.method()만 호출하고 이 method가 요청에 대한 비즈니스 로직을 전부 담당하게 되었습니다.@Service class QuestionPaymentService( private val questionOrderGenerator: QuestionOrderGenerator, private val promotionApplier: PromotionApplier, private val orderCouponApplier: OrderCouponApplier, private val paymentCouponApplier: PaymentCouponApplier, private val questionPaymentRecorder: QuestionPaymentRecorder, private val pointCommandAPI: PointCommandAPI, private val eventPublisher: EventPublisher, ) { @Transactional fun payment(command: QuestionPaymentCommand): QuestionPayment { val order = questionOrderGenerator.generateQuestionOrder(command.userId, command.questionIds) val questionPayment = QuestionPayment.create(command.userId, order) promotionApplier.apply(order) orderCouponApplier.apply(questionPayment, command) paymentCouponApplier.apply(questionPayment, command) pointCommandAPI.usePoint(questionPayment.userId, questionPayment.realAmount) questionPaymentRecorder.record(questionPayment) eventPublisher.publish(toEvent(questionPayment)) return questionPayment } }위 코드는 제 프로젝트의 결제 부분인데요. 강의에서 말씀하신 것처럼 Service가 너무 많은 걸 알게되더라구요.(주문도 생성하고, 쿠폰도 적용하고, 프로모션도 적용하고...)지금 이 글을 작성하다보니, 갑자기 제 코드가 못생겨보이네요..강의 코드와 비슷한 방식으로 위 코드를 바꿔본다면, 컨트롤러에서는 orderService를 이용해서 주문을 생성하고, couponService, promotionService 등을 이용해서 전처리를 한 뒤 PaymentService을 이용해 실 결제 금액만큼 금액을 지불하도록 하는 로직과 결제 내역을 저장하는 로직만 있을 것 같아요. 반대로 제 프로젝트 방식대로 강의 코드의 payments API를 만들어본다면, Payment를 만들기 위해서PaymentCreateService와 같은 곳에서, orderReader, ownedCouponReader, pointReader 등을 조합해서 Payment를 생성하는 방식이 될 것 같아요.결국 Service가 적은 책임만 가지게 된다면, Controller 입장에서는 복잡한 요청을 처리하기 위해선 다양한 Service를 조합하게 되고 Controller가 비즈니스 로직의 흐름을 보여주는 형태가 될 수 있다고 생각이 드는데요.(사실 Controller가 비즈니스 로직의 흐름을 보여주면 안된다는 걸 어디서도 듣지 않았지만 뭔가 어색한 것 같아요.)물론 계속 말씀하시는것 처럼 정답은 없다는 것은 알지만, 그냥 단순히 재민님은 주로 많은 책임을 가지는 Service보다는 Controller에서 작은 단위의 Service로 조합해서 처리하는 것을 선호하시는지 궁금합니다.재민님을 지속 성장 가능한 소프트웨어 포스팅으로 알게되었고, 유튜브에서도 많은 도움이 되었어요.그렇게 얻은 다양한 인사이트들을 개인 프로젝트에도 적용해보면서 다양한 시도를 하고 있는데 마침 제 관심사인 커머스 주제로 강의가 나와서 정말 행복합니다.

1강 2:59 와 3:56 같은 내용인가요? 중복되는 것 같은데요. demo를 두 번 만드시는건지 헷갈립니다. 

kafka 강의 부터는 아직 최신 버전으로 영상이 업데이트 되지 않은거 같은데 혹시 올해 업데이트 될 예정일까요??업데이트가 된다면 이 후에 강의를 듣고 싶어서요!!

MemberFinder 와 같은 유즈케이스 단위로 통합 테스트를 분리 해서 작성하셨는데 단위 테스트의 경우에는 분리를 어떻게 하시나요? MemberService (Query, Modify) 가 없이는 코드가 작성이 되질 않아서 질문 드립니다.  

안녕하세요. 궁금한게 있어서 질문 드립니다.domain 패키지에 entity를 위치 한다고 했을때 주석이라고 말씀하신 어노테이션 JPA @Entity를 만들어서 Member로 정의그리고 mongo DB도 필요해서 @Document를 정의해서 domain 패키지에 위치 시켜 Member로 정의이처럼 같은 도메인이 서로 다른 DB로 사용 될때 어떻게 도메인으로 정의해야할지 궁금합니다.그리고 이름이 중복되는 현상도 발생하기도 합니다. 그렇다고 OracleMember, MongoMember로 지을수도 없는것같습니다. 제 생각은 Member라는 도메인이 Domain 패지키에 별도로 나와서 adapter 안에 JPA Persistent의@Entity로 정의된 클래스와Mongo Persistent의 @Document로 정의된 클래스가 위치 되어야한다고 생각하는데 어떤 의견이신지 궁금합니다.

지금 Swagger 적용하기 보고있는데Application.kt 파일 을 작성하는데스프링이 적용이안돼는지 어노테이션 이 원래 빨갛고 노랗게 떠야하는데 안뜨네요강의보고 따라하는중인데 어떻게해야될지 잘모르겠습니다

안녕하십니까 코드빌런님.이번 추석 연휴동안 레빗 엠큐 강의 잘 들었습니다. 다름이 아니라 강의에서 알려주신 여러 내용을 바탕으로 기존에 구현하였던 redis pub/sub 기반의 알림 기능에 레빗 엠큐를 적용해보고 있습니다. 그리고 구현 중 두가지 질문이 있어 질문을 작성하게 되었습니다. 1. 동적 큐 이름 설정 방식우선 알림을 전송하는 과정에 대해 말씀드리면 다음과 같습니다.알림 객체 저장성공 시 알림 발송sse 연결들을 ConcurrentMap으로 관리하여 대상 userId의 sse연결을 찾아 해당 연결로 알림 객체 전송 현재 메시지 큐 구조는 다음과 같습니다. 알림 저장 메시지 생성 (direct exchange, saveNotificationQueue) -> 메시지 저장 성공 시 알림 전달 메시지 생성 (fanout exchange, publishNotificationQueue), 메시지 저장 실패 시 데드레터 큐로 전달 현재 서비스는 3개의 인스턴스로 동작하고 있습니다. 이때 알림 저장 큐는 1개라서 복수 저장될 일이 없지만, 그 후에 진행되는 알림 전달의 경우 단일 큐로 작동하면 대상 sse 연결이 없는 인스턴스에서 해당 메시지를 소비하게 되면 전송이 실패합니다. 그래서 각 인스턴스마다 큐를 만들어주고 fanout exchange에 모두 바인딩하여 사용하는 방식으로 만들어야 할 것 같다고 생각하였습니다. 그래서 찾아보니 SpEL 기반 동적 큐 이름 지정 방식이 있다고 하여 해당 방식으로 구현해보았습니다.// RabbitMQConfig.java // 알림 발송 큐 @Bean public String dynamicPublishNotificationQueueName() { String randomString = UUID.randomUUID().toString(); return PUBLISH_NOTIFICATION_QUEUE + " : " + randomString; } @Bean public Queue publishNotificationQueue() { return new Queue(dynamicPublishNotificationQueueName(), false); } @Bean public FanoutExchange publishNotificationExchange() { return new FanoutExchange(PUBLISH_NOTIFICATION_EXCHANGE); } @Bean public Binding publishNotificationBinding() { return BindingBuilder.bind(publishNotificationQueue()).to(publishNotificationExchange()); } // NotificationSubscriber.java @RabbitListener(queues = "#{@dynamicPublishNotificationQueueName}") public void consumePublishNotificationMessage(Notification notification) { notificationService.publishNotification(notification); }해당 방식으로 정상 작동은 확인하였는데, 혹시 해당 방식 외에 더 나은 방식이 있는지 궁금합니다.2. SimpleRabbitListenerContainerFactory의 재정의에 따른 Retry 설정 미적용강의 18강에서 application.yml에 retry 관련 프로퍼티를 설정하는 것만으로 자동으로 retry가 적용된다고 하여 해당 방식을 프로젝트에 적용해보았습니다. spring.rabbitmq.listener.simple.retry.enabled=true spring.rabbitmq.listener.simple.retry.initial-interval=1000 spring.rabbitmq.listener.simple.retry.max-attempts=3 spring.rabbitmq.listener.simple.retry.max-interval=1000 spring.rabbitmq.listener.simple.default-requeue-rejected=false하지만 어떤 이유인지는 몰라도 retry가 작동하지 않았습니다. 실제로 실행되는 코드에 로그를 찍어봐도 한번만 시도하고 설정한 예외가 발생 후 바로 DLQ로 이동하였습니다. 그래서 원인을 찾던 도중https://inf.run/bsxxr에서@RabbitListener를 사용하면 내부적으로 SimpleMessageListenerContainer가자동으로 생성되기 때문에 retry 설정을 읽어서 exception 이 발생할 경우 RetryTemplate을 사용해서 자동으로 설정된 속성에 해당하는 작업을 수행하게 됩니다.라고 코드빌런님이 말씀하신 것을 보았습니다.확인해보니 메시지큐에서 객체 자동 역직렬화를 위해@Bean public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory(ConnectionFactory connectionFactory) { SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); factory.setConnectionFactory(connectionFactory); factory.setMessageConverter(messageConverter()); return factory; }이렇게 SimpleRabbitListenerContainerFactory를 정의하여 빈으로 등록해놓았는데, SimpleRabbitListenerContainerFactory를 살펴보니public class SimpleRabbitListenerContainerFactory extends AbstractRabbitListenerContainerFactory<SimpleMessageListenerContainer> { ...말씀하신 SimpleMessageListenerContainer를 타입파라미터로 받아 상속받고 있는 형태였습니다. 이에 말씀하신 SimpleMessageListenerContainer가 자동으로 생성되어 retry 설정이 적용안되는것인가? 라고 예상하여 application.properties에 정의하는 대신 @Bean public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory(ConnectionFactory connectionFactory) { SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); factory.setConnectionFactory(connectionFactory); factory.setMessageConverter(messageConverter()); factory.setDefaultRequeueRejected(false); factory.setAdviceChain(RetryInterceptorBuilder.stateless() .maxAttempts(3) .backOffOptions(1000, 2.0, 10000) .build()); return factory; }이렇게 직접 retry 설정을 넣어주니 그제야 재시도가 정상적으로 작동하였습니다. 해당 원인이 제가 생각한 직접 팩토리를 Bean으로 등록하면 application.properties의 retry 설정이 무시되는 것이 맞는지 궁금합니다. 코드는 아래 url에서 보실 수 있습니다.https://github.com/Dockerel/4th-SC-TEAM1-BE/pull/15/files 강의 정말 잘 들었습니다! 이렇게 프로젝트에 바로 적용해볼 수 있어서 기분이 좋네요.나중에 코드빌런님의 다른 기술 스택 강의도 들어보고 싶습니다.감사합니다.