학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.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 강의 정말 잘 들었습니다! 이렇게 프로젝트에 바로 적용해볼 수 있어서 기분이 좋네요.나중에 코드빌런님의 다른 기술 스택 강의도 들어보고 싶습니다.감사합니다.

안녕하신가 미스터 KILL-9항상 빠르고 친절한 답변 고맙다 이번에 회사 로직 작성중에 조금 막막한 부분이 있어 질문 하러 왔다 reader 엑셀 파일 읽어오고processor 에서 해당 엑셀 데이터 값을 가지고 dao 호출해서 검증하고, 깍고(가공)마지막으로 쓰기 처형하는데 작업을 하는데문제는 가공 단계에서 dao 를 직접 호출하면ExecutorType 이 simple 로 호출되고 쓰기 단계에서 batch 로 ExecutorType 실행되어 에러가 발생한다Cannot change the ExecutorType… 이렇게 말이다..그래서 일단 아래 코드 처럼 해결은 했어 우선 기존 코드는  PoiItemReader -> ItemProcessor<> (여기서 mybatis dao 호출 해서 검증작업도 함) -> MyBatisBatchItemWriter -> 에러 Cannot change the ExecutorType…  해결한 코드  PoiItemReader -> ItemProcessor<> (여기서 mybatis dao 호출 해서 검증작업도 함) -> JdbcBatchItemWriter-> (해결)그런데 이렇게 작성해도 되려나 싶네.. 그리고 String 문으로 쿼리 짜는것도 맘에 안들고..ㅠㅠ

- 명백한 한계점 (단점): - 네트워크 대역폭 소모: 실제 데이터를 전송하므로 네트워크 부하가 극심하다. 데이터 건수가 많거나 크기가 크면 통신 자체가 병목이 될 수 있다. ("핵탄두 데이터 전송에 따른 통신망 과부하 주의!") - Manager 읽기 병목: Manager 혼자 모든 데이터를 읽어야 하므로, 읽기 자체가 느리다면 원격 청킹은 효과가 없다. ("중앙 정찰 위성의 스캔 속도 한계!") - 복잡성(감시와 디버깅의 지옥문): 역시 미들웨어(Kafka 등)와 프링 인티그레이션 설정이 필수적이다.프링 인티그레이션 ->스프링 인티그레이션

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요, 선생님! 강의 알차게 잘 수강하고 있습니다.현재 90% 수강 완료하였는데, 어렵고 힘들게 여기까지 온 만큼 저의 역량도 비교할 수 없을 정도로 많이 성장한 것 같습니다.먼저 감사의 말씀을 드립니다.일단 현재 게시글 목록 최적화 전략 구현(64강) 강의를 수강 중인데, 이전의 강의 내용(게시글 조회 최적화 전략)과 비교하였을때 최적화 전략을 수립하는 과정과 관련하여 몇가지 의문점이 들어 질문드리게 되었습니다.의문점) - 게시글/카테고리에 대한 게시글 목록 모두 전략을 나누어야 하는가?의문점이 들었던 과정) - 일단 크게 보았을때, 게시글 내용에 대한 캐싱(articleId)과 게시글 목록(*특정 카테고리, board로 지칭)에 대한 캐싱(boardId)으로 내용을 나눌 수 있을 것 같습니다.- 여기서 드는 제 개인적인 생각은, (일단 전략의 당위성이나 세부적인 내용 상관없이) 캐싱전략을 너무 세세하게, 오히려 성능적 이점보다는 관리적 비용이 더 크게 소모되지 않을까 하는 염려가 들 정도로 배꼽이 더 큰 전략/관리방안을 각각 구분해놓는 것이 아닌가하는 생각이 들었습니다.- 예를 들어, 게시글 목록 최적화 전략의 경우 말씀하신대로 최초 목록 조회 진입 시 보여지는 내용이기도 하고 이는 모든 사용자에게 공통적으로 적용할 수 있는 정책이므로 관리의 당위성이나 책임이 명확하다고 생각하였습니다.- 하지만 게시글 조회 최적화 전략의 경우, 목록 최적화 전략을 수강한 이후에는 "게시글 조회"역시 어떻게 보면 그 게시글을 보고싶은 사용자 일부에 대해서만 보여지는 글이므로..지금처럼 모든 생성 글/댓글/좋아요에 대해 ArticleQueryModel 데이터를 생성하는 것이 비용효율이나 관리효율면에서 과연 올바른 방향인지 다소 의문이 들게 되었습니다. 또한, 이러한 전략수립의 당위성을 떠나서 각 조회기능별로 전략을 구상하는게(단건/목록 등) 수립은 가능하더라도 관리가 힘들 것 같은데, 실무적으로 관리가 가능할지 의문이 들기도 하였습니다.최종 질문)- 제가 올바르게 강의내용을 이해하지 못하여 질문드리는 것 일 수 있기에, 일단 제가 들었던 의문이 선생님께서 생각하셨을때, 타당한 의문일지 궁금합니다.- 타당하다면 아래와 같은 "게시글 단건" 조회 전략을 생각할 수 있을 것 같은데, 혹시 바람직한 전략이 될 수 있을지 고견을 요청드려보고자 합니다.- 또한 실무적으로 이러한 다양한 관리전략을 수립하게된 계기가 "성능문제" "사용자 패턴에 따른 문제점 예상" 등, 여러 문제 중 어떠한 부분이 가장 중요하게 작용하는지 궁금하여 질문드립니다.[단건 조회전략 구상 방안] 게시글 조회 전략을 만약 구상한다면(세부적인 전략구현은 생략)- 지금처럼 단건 데이터 생성마다 articleQueryModel을 구성하는 것이 아니라, 각 카테고리별 보여지는 1000개의 데이터에 대해 articleQueryModel 데이터를 구성한다. (*게시글을 보는 것도 결국 최신 1000개의 데이터에 대해서만 볼 것이기 때문이다.)- 인기글 데이터 생성 후 해당 인기글에 대한 articleQueryModel 데이터를 구성한다.(*인기글 데이터에 대해서만 단건 조회 트래픽이 몰릴 것으로 예상할 수 있기 때문이다.)읽어주셔서 감사드립니다.

안녕하세요.질문 먼저 요약하자면,id token 에 scope에 포함된 유저 정보가 같이 포함되어 넘어오는게 일반적인지, idtoken 검증만 진행한 뒤 액세스토큰으로 따로 조회하는게 일반적인지 궁금합니다. 1년쯤 전에, 소셜 로그인의 흐름을 이해해보기 위해 스프링 시큐리티 없이 카카오, 네이버, 구글 로그인을 적용해본 적이 있습니다.원래 카카오와 구글은 OIDC를 지원했고, 네이버는 OIDC가 없었는데 최근에 추가되었더라구요.그래서 OAuth2 스펙으로만 구성된 네이버 로그인 코드를 OIDC를 적용한 코드로 수정하고 있었는데.. 그러다가 의문이 생겨서 질문을 드리게 되었습니다. 저는 여태까지 필요한 유저 정보의 scope를 "openid" 항목과 함께 프로바이더에 전달하고,id token을 프로바이더로부터 전달받고, 그걸 검증한 뒤 id token에 담긴 유저 정보를 사용하면 된다고 생각하고 있었습니다.실제로 카카오와 구글은 유저의 email 정보가 id token 페이로드에 담겨있었구요. 네이버 역시 https://nid.naver.com/.well-known/openid-configuration 의 메타데이터 중 scopes_supported 항목을 확인했을때 profile이라는 scope가 존재해서, 코드 요청할때 scope=openid+profile 을 파라미터로 전달했습니다.그런데 id token을 확인해도 유저의 정보가 나오지 않더군요. 처음에는 단순히 네이버가 이 부분을 미구현했나? 생각을 했는데, 좀 찾아보니 id token에는 최소한의 신원만을 포함하고 세부적인 프로필은 따로 조회하는게 맞다는 말도 있더라구요. 그래서 질문을 올리게 되었습니다.

안녕하세요!다른 분 질문에 대한 답변을 보고 기본적인 의구심은 해소되었는데요. 혹시 몰라 확인차 여쭙습니다.09:38 피피티에서요.나머지 연산을 이용해서 물리샤드, 논리샤드를 구분하셨잖아요.제가 이해하기로 나머지가 0이면 1번 샤드, 1이면 2번 샤드...이렇게 의도하시려고 했던 것 같아요.https://inf.run/7i72V여기에서 답변해주신 것과 피피티의 샤드 번호 현황?이 달라서 조금 혼란스러웠습니다. 링크 답변을 보면 아주 간단한 샤딩 예시였지만, 물리 샤드가 두 개일 때 % 2를 적용하면 1번 샤드(나머지 연산결과 +1)에는 article_Id가 [2, 4, 6, 8]이 들어가고 2번 샤드에는 [1, 3, 5, 7]이 들어갈 테죠.논리 샤드 기준으로는1번 논리샤드 = [4, 8]2번 논리샤드 = [1, 5]3번 논리샤드 = [2, 6]4번 논리샤드= [3, 7] 1번 물리 샤드에는 1, 3번 논리 샤드2번 물리 샤드에는 2, 4번 논리 샤드(링크 답변과 동일한 분포)이게 제가 위의 답변을 강의 자료에 적용해서 이해한 샤딩 현황입니다! 실제 프로덕션에서도 이렇게 샤딩하는지는 모르겠지만 교육 목적 상 간단한 해싱이었어도 제대로 이해하고 넘어가고 싶었습니다.PPT만 보고는 나머지 연산이 어떻게 사용된 건지 이해가 안 됐는데 답변 보고 이해가 돼서 확인 차 질문드렸습니다.추가적으로 클라이언트는 논리 샤드만 알고 있다고 하셨는데 그럼 물리 샤드 번호는 물리적으로 나뉜 샤드를 구분하는 데만 사용하고 비즈니스 로직에서는 사용되는 일이 없을까요?감사합니다.

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]여기에 질문 내용을 남겨주세요. 제목 그대로 오류가 나구요. 원본 코드를 옮겨봐도 의존성 문제인지 오류가 납니다 https://drive.google.com/file/d/1yRhCS0euBPt9YqDHOrYB4kE9A3-QcBjR/view?usp=drive_link

안녕하세요 실무에서 헥사고날을 적용 예정 중에 있습니다. 이미 DB 모델링이 되어 있고 하나의 우리 팀 시스템이 아닌 여러 팀의 시스템에서 같은 테이블을 바라보는 경우 헥사고날 적용은 어떻게 해야하는지 궁금합니다. 하나의 애그리거트로 만들 수 없는 여러 엔티티의 조합으로 조회를 할 경우, 예를 들어 백오피스에서 20개 이상의 조건과 각 조건이 여러 테이블에 나뉘어져있어 Join을 걸어야 할 경우의 도메인 모델과 리턴은 어떻게 해야하는지 궁금합니다.

KILL-9: "이 구성이 매우 중요하다. Job 설정을 보면, logFileManagerStep()이 먼저 실행되고, 그 다음에 mergeOutputFilesStep()이 실행되도록 .next() 메서드로 연결되어 있다.없어도 뻔해서 이해되긴하는데,위의 예제에서 Job빈이랑 LogFileManagerStep빈(이건 일부러?) 빼먹은듯?KILL-9: "이 구성이 매우 중요하다.로 검색하면될거야------그리고 그냥 궁금한건데,이번강의챕터가 컨셉자체는 맘에드는데(코드랑 내용이랑 같이 스토리넣어서 말하는거)인프런 강의 시스템상 너무 보기힘들지않아?부록 2: 전장 구축 - Redis to MongoDB 데이터 이관 작전 환경 설정같은거보면,나는 가로휠이 있어서 괜찮았는데 가로휠마우스가 없으면 마우스 드래그로 컨트롤하거나 키보드 화살표로 조금씩 밀어야하는데 이거 너무 보기 힘들거같아스크롤바도 내용화면이 한페이지를 넘어가면 안보이고 그래서다음거 스카이넷보고서인지 그런식으로 개행을 넣던가 하면될거같긴해킬구<스카이넷 ?다음거 원격 파티셔닝 강의 대부분 그냥 서두보고 다 스킵할거같은데,@ConditionalOnProperty로 조건부 빈생성 관리하는거 스킵되는거 아까운데 이거나 줏어가라고 마지막 부록에 넣어줄만하지않음?나도 그냥 내용 대충 훑어만봤는데 저거하나는 건진거같아서

안녕하세요.강의 정말 잘 들었습니다. 강의를 듣다가 궁금한 점이 있어 질문 남깁니다.Member와 MemberDetail을 별도 엔티티로 분리한 기준이 궁금합니다.관계가 1:1인 경우에는 엔티티에 너무 많은 필드가 있는 것이 아니면 하나로 관리하는 게 더 개발 편의성이 좋지 않을까? 하는 생각이 들기도 합니다. 실제로 회원 정보 수정 시에 닉네임, 프로필 주소, 자기소개를 한 번에 변경하도록 구현되어 있어, 두 엔티티가 함께 조회/수정되는 것처럼 보입니다.혹시 조회 성능 최적화를 위해 접근 빈도가 낮은 데이터를 지연 로딩하려는 의도인지, 아니면 회원의 본질적 속성(email, status 등)과 부가 정보(등록일시, 프로필 등)를 개념적으로 구분하기 위한 설계인지 궁금합니다.감사합니다.

쿠폰에 관련되어서 좀 더 참고할만한 자료가 있을까요?

55강 수강 중 client credentials 방식으로 변경 후 테스트 시 이런 에러가 발생합니다. 왜 그런걸까요 ㅜㅜ