안녕하세요!강의를 새로 구매했는데, 이전에 구매했던 강의 내용과 겹치는 것 같아수강하기 전에 미리 여쭤봅니다! [이전에 구매했던 강의]면접 전에 알고 가면 좋을 것들 - 신입 Java 백엔드 개발자편 [새롭게 구매한 강의]모든 웹 개발자가 봐야 할 단 한 장의 지도 혹시 새롭게 구매한 강의가 기존에 있던 강의 내용과중첩되는 내용일까요? 감사합니다.  

강의를 보다보니 궁금한 점이 있어 질문 남깁니다. 첫번째로 궁금한 점은 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를 사용하지 않는 또 다른 모듈에서 사용한다는 가정 밖에 떠오르지 않습니다.혹시 다른 이유가 있을까요?

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

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

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

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

안녕하세요.결제 부분 강의를 보니 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로 조합해서 처리하는 것을 선호하시는지 궁금합니다.재민님을 지속 성장 가능한 소프트웨어 포스팅으로 알게되었고, 유튜브에서도 많은 도움이 되었어요.그렇게 얻은 다양한 인사이트들을 개인 프로젝트에도 적용해보면서 다양한 시도를 하고 있는데 마침 제 관심사인 커머스 주제로 강의가 나와서 정말 행복합니다.

안녕하신가 미스터 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 등)와 프링 인티그레이션 설정이 필수적이다.프링 인티그레이션 ->스프링 인티그레이션

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

안녕하세요.nestJS강의를 잘 시청하고있습니다.진행하는 과정에서 Socket Connect 연결 요청시 Error: socket hang up 오류가 발생하며 연결이 되지 않는 문제가 발생 하였습니다.저는 현재 NestJS최신버전인 11.1.6버전을 이용해 진행중입니다.PostMan에서 Connect 시도시 아무런 로그가 남지 않습니다.혹시 아래 문제에 대해서 도움을 받을 수 있을까요?  

안녕하세요, 선생님.강의 잘 들었습니다. 많은 도움이 되었습니다. 감사합니다.현재 저는 IT 영업 직무로 근무하고 있습니다.회사에서 운영하는 프로그램을 SaaS형, API 연동형, SI 구축형의 세 가지 방식으로 판매하고 있습니다.SaaS형의 경우 프로그램 기능을 익히면 비교적 단순한 영업이 가능하지만,API 연동형이나 SI 구축형 영업의 경우 웹의 흐름과 인프라 구조에 대한 이해가 필요할 때가 많습니다.이런 이유로 IT 용어나 개념을 익히려 노력하고 있으나,내용이 생소하고 설명이 어렵게 느껴져서 어려움을 겪고 있습니다.다행히 개발 직군은 아니어서 깊은 기술 지식까지는 필요하지 않지만,고객사 IT 담당자와 원활하게 커뮤니케이션할 수 있을 정도의 이해도는 갖추고 싶습니다.혹시 선생님의 강의 중에서 이런 상황에 도움이 될 만한 강의가 있을까요?만약 없다면, 어떤 방식으로 공부를 시작하는 것이 좋을지도 조언 부탁드립니다.

강의 해주셔서 감사합니다!강의 내용중에 인스턴트 와 JOSN을 설명주셨는데,따로 찾아봤는데 어렵게 설명이 되어있어서쉽게 설명해주실 수 있나요?특히 인스턴트는 무슨말인지 도저히 모르겠습니다..

$ kill-9.. 킬구형 추석 연휴는 잘 보냈는가.. 처음에 텍스트로만 구성된 강의인 걸 결제한 후 알게되어 당황했지만.. 걱정 마라.. 금방 킬며들었다.. 눈으로 읽고 생각하는 즐거움을 알게되었다.. 무엇보다 그동안 피로했을 내 귀를 지켜줘서 고맙다.. 아직 강의 초반이지만 궁금한 부분이 있어서 질문 올린다.. 대용량 트래픽을 다루는 회사에서는 배치 메타데이터의 양도 어마어마할 것 같은데 실무에서는 배치 메타데이터를 어떻게 관리하는 지가 궁금하다.. 혹시 배치 메타데이터를 활용할 일이 없을 것 같으면 안쌓는 것도 권장하는 방법인가.. 

검색을 해보니 강의 내용 중 나오는sql인젝션xss, HttpOnlycsrf, SameSitehttps이 부분들은 보통 기본적으로 많이 선택해서 꼭 알아야 하고 연습해야 하는 것으로 생각됩니다그 외에도 알려주신 것들에 대해 자세히 알아야 할까요? 아니면 이런 방법들이 있구나 하고 굳이 직접 사용해볼 필요는 없는 걸까요

킬구형 텍스트 강의임에도 몰입감 있는 구성에 연휴에 재밌게 공부하고 있어. 고마워FlatFileItemWriter에 대한 흐름을 정리하고 질문 해볼게1. sourceType() 메서드 내 객체 타입에 따라 FieldExtractor 구현체가 결정된다.2. (Bug가 fix되기 전까지) sourceType() 메서드 내 객체 타입이 Record일 경우 names() 메서드 호출은 무시되고, Record 타입의 모든 property가 쓰일 수밖에 없다.3. 그렇기에 Record 타입에서 필드 하나를 제외하고 파일을 쓰고싶다면, fieldExtractor()를 사용한 커스텀 구성을 통하여 필드 하나를 제외해야 한다.내가 강의를 보면서 정리한 흐름이고, 아래는 그 정리 중 나온 질문이야Q1. BeanWrapperFieldExtractor일 경우 필드 하나를 제외하고 싶다면, names()에서 해당 필드만 제외해도 되나? Q2. 만약 위와 같은 방법이 된다면, RecordFieldExtractor 관련 Bug가 fix 된 후에 FieldExtractor를 직접 커스텀하는 경우가 별로 없지 않을까 싶은데.. 혹시 내가 생각하지 못한 부분이 있을까?고마워 킬구형아

안녕하세요!덕분에 아키텍처에 대한 큰 그림을 그려보며 강의를 듣고 있습니다. MSA 전환 시점 관련해서 질문 드립니다.모놀리식 아키텍처에서 MSA로 전환하는 적절한 시점은 어떤 기준으로 잡는게 좋을까요?물론 상황마다 다르겠지만, 강사님은 어떤 기준을 가장 중요하게 생각하시는지 궁금합니다.예를 들어, Scale-out 한계, 빌드&배포 시간 증가, 혹은 서비스 크기와 복잡성 같은 요소들.. 이 있을 것 같은데 제가 미처 생각 못한 부분이 있다면 덧붙여 답변 부탁드립니다.감사합니다!