강사님은 Classicist 쪽에 속하셔서 Service를 테스트할 경우 Repo도 포함한다고 하셨었는데 Controller에서는 MockMvc를 활용하셔서 따로 테스트한 것으로 알고 있습니다.컨트롤러 - 서비스, 레포지토리의 관계와 서비스 - 레포지토리의 관계에서 어떤 차이점 때문에 이렇게 구성하신 것인지 궁금합니다.

이론 부분을 제가 이해를 잘 못해서 질문드리는 것 같은데요,Kafka와 Debezium 까지의 전반적인 그림은 그려지는데temporal(acitivity나 workFlow클래스 등) 까지 합쳐졌을 때의 플로우가 잘 이해가 가지 않는데구상하신 아키텍처를 모두 합친 플로우가 궁금합니다!

교육을 듣다보니 Temporal에 대해서 더 알고 싶은데Temporal 공식 사이트는 너무 방대하고, 사용법 위주로 설명되어 있어서, 혹시 내부 아키텍처 같은 내용을 참고할 수 있는 자료가 있을까요?

안녕하세요 토비님! 순수한 궁금증이 생겨서 질문 드립니다!아키텍처마다 장단점이 있다고 생각합니다. 프로젝트의 규모나 확장성 여부에 따라 어울리는 아키텍처가 다를 것 같은데요, 토비님은 현업에서 어떤 기준을 가장 중점적으로 두고 아키텍처를 선택하시는지 궁금합니다!

안녕하세요. 오브젝트와 인스턴스에 대해 제가 기억하고 있는 비유가 하나 있습니다."오브젝트가 소나타라면, 돌아다니는 소나타 하나 하나가 인스턴스이다."이 비유는 적절한 비유인가요? 혹은 오해의 여지가 있는 비유일까요?

서비스를 소형 단위로 테스트하기 위해 Fake 클래스를 구현하는 실습을 진행하셨는데요.테스트 코드는 결국 구현된 기능이 정상적으로 동작하는지 검증하기 위한 것이라고 생각하는데요~그런데 H2 DB를 직접 띄워 테스트하는 방식과 비교했을 때, Fake 객체를 활용한 방식은 구현 방식에 따라 실제 동작과의 괴리가 생길 수도 있을 것 같은데, 이런 접근이 실제로 효과적인 테스트 방법인지 궁금합니다!

안녕하세요 토비님테스트 코드를 이용한 테스트 강의 내용 중 helloApi를 테스트하기 위해 TestRestTemplate를 사용해서 테스트 코드를 작성하고 있는 부분을 진행하고 있습니다. 강의에서는 아래의 화면 같이 테스트 수행 시 TestRestTemplate 의 Http 요청과 응답에 대한 로그가 남는데, 제가 실행했을 때(2번째 사진)는 전혀 남지 않습니다.아래는 제가 직접 실행한 결과이고, junit5 을 통해 실행했을 때나, gradle 을 통해 테스트를 실행했을 때 둘다 강의와 같이 웹 요청/응답에 대한 로그가 남지 않습니다. 테스트는 성공적으로 수행되어서 요청은 제대로 전송되고 응답받는걸로 확인되고 있고, 어짜피 성공한 테스트니까 무시해도 좋겠지만 강의대로 콘솔에 로그가 안남으니까 조금 찝찝합니다,, 웹에서 검색을 해봐도 해결방법이 안나오네요 ㅜㅜ저는 스프링부트 3.5.6 버전, java 17을 쓰고 있고 Intellij는 Ultimate을 사용하고 있습니다. 강의와 달리 스프링부트 버전이 향상되면서 관련 로그가 남지 안도록 된 건지, 단순히 설정이 잘못되었을 수 있을지,, 질문드립니다. 감사합니다.

안녕 킬구형 형 때문에 이번 추석 연휴 재밌게 보내고 있어. 고마워 형. 강의를 보면서 예제 소스에 대한 궁금증이 생겨서 질문을 남겨. 6장. 작전4: 원격 청킹 (Remote Chunking) - 전방위적 타격이 시작되다. ☠ '데이터 변화 모듈(SerDes Classes)' 예제에서 예외 객체로 MessageConversionException을 사용하는데 클로드에서는 통상 Kafka를 사용할때는 org.apache.kafka.common.errors.SerializationException 을 사용해야 kafka와 호환이 된다고 하더라구. 이거에 대해 설명 부탁해도 될까?

형 아직 잘 이해가 안되서 그러는데, Job 안에서 Chunk 방식 Step과 Tasklet 방식 Step을 혼합해서 사용하는 실무 예시를 알려줄수 있어?

아직 스프링부트 강의까지는 수강하지 못해서 남기는 질문입니다. 만약 프로젝트가 처음부터 스프링부트 환경이라고 한다면 별도로 @SpringBootTest 같은 애노테이션은 사용하지 않아도 되나요?@TestConfiguration의 경우에 꼭 내부 클래스로만 사용해야하나요?

안녕하세요. 강의 잘 듣고있습니다.강의를 듣다보니 실무에서는 어떤식으로 waitTime, leaseTime을 정하는지 궁금해서 질문드립니다.강사님께서는 어떤 테스트와 어떤 생각으로 waitTime, leaseTime을 정하시나요?

킬구형 Spring Data JPA 사용하면 JpaRepository 인터페이스를 사용해서 PlatformTransactionManager, DataSource를 자동으로 주입받아 사용할 수 있는데, 강의에서는 스프링배치의 세밀한 조정을 위해 일부러 JpaRepository를 사용하지 않는 거야?아래 두 강의에 둘 다 데이터소스와 트랜잭션매니저를 직접 활용하고 있어서 궁금해서 물어봐3장. 작전1: 관계형 데이터베이스 읽고 쓰기 (테이블의 심장에 처형장을 세우다 ☠)OPERATION DOUBLE TAP - Spring Batch Test(추가) 생각해보니 예전에 아주 간단한 로직의 스프링배치 앱을 JpaRepository, JPQL을 이용해서 만들었던 만들었던 기억이 있는데,, 혹시 JpaRepository을 일부러 사용하지 않는 이유가 있는지 궁금해

강의를 NestJS로 적용해 따라가고 있습니다. 마지막 “ArchUnit을 이용한 아키텍처 테스트” 파트에서 Node/NestJS 환경에서는 어떤 방식으로 아키텍처 규칙을 테스트/검증하는 것이 좋은지 궁금합니다.자바에서는 ArchUnit으로 레이어 규칙, 패키지 의존성, 순환 참조 등을 명시적으로 검사할 수 있는데, Node 진영에서는 유사한 도구로 무엇을 추천하실까요? 제가 찾은 것은 “ts-arch”였고, 폴더/슬라이스 의존성, 사이클 검사를 지원하는 것으로 보입니다. 적용을 하다가 실패를 했는데, 다른 방법이 있다면 조언 부탁드립니다. 😭😭😭

안녕하세요, 강의 정말 잘보았습니다!!Part1을 전부 보고 나니까 part2가 언제쯤 나올지 궁금해서 질문남깁니다!

스프링을 사용하는 이유 중 하나가 스프링 컨테이너를 통한 의존성 주입(DI)이라고 알고 있습니다.그러면 스프링 컨테이너가 Bean을 관리하기 때문에, 자동으로 싱글톤 패턴이 적용된다고 이해해도 될까요?

=========================================[질문 내용]안녕하세요, 영한님? 영한님의 자바와 스프링 전편의 로드맵을 수강 중인 개발자입니다. 항상 영한님의 강의를 들으며 스텝업하는 부분이 있기에 너무 감사하단 인사를 먼저 드리고 싶습니다. 본격적인 질문은 스레드 로컬을 포함한 멀티 스레딩 관련 내용입니다. 영한님의 유튜브 영상 중 초보 개===============================[질문 내용]안녕하세요, 영한님? 영한님의 자바와 스프링 전편의 로드맵을 수강 중인 개발자입니다. 항상 영한님의 강의를 들으며 스텝업하는 부분이 있기에 너무 감사하단 인사를 먼저 드리고 싶습니다.    영한님의 유튜브 영상 중 고민 많은 개발자가 찾아왔다 를 보고 저 역시 처음부터 높은 목표를 가지지 않고 당장 입사 가능한 회사에 들어가 1년간 업무를 해봤습니다. 그래서 그런지 몰라도 이전 회사에선 영한님 강의에서 배운 내용들을 10% 조차 적용하지 못해봤던 것 같고 그 부분에 회의를 조금 느낀 것인지 안주하지 않겠다는 생각을 가지고 퇴사 후 교육을 듣게 되었던 것 같습니다.  본격적인 질문은 스레드 로컬을 포함한 멀티 스레딩 관련 내용입니다. 자바 고급편에서 다뤄주신 executorService나 이번의 스레드 로컬과 같은 멀티스레드 관련 지식을 적용할만한 코드가 이전 회사에선 없었습니다. 기껏해야 비동기 API 구성시 Future를 사용한 것 정도일까요? 그래서 궁금해졌습니다. 스프링 부트에서는 기본적으로 대부분의 컴포넌트가 싱글톤 스코프로 관리되기 때문에, stateless하게 설계하면 일반적으로 스레드 안전성 문제가 드물다고 알고 있습니다.다만 실무에서는 의도치 않게 stateful한 코드가 들어가는 경우가 자주 발생하곤 하는데요.(그게 실수가 되었건 불가피하건 말이죠)> 실제로 규모가 있는 서비스 회사에서는 이런 문제를 사전에 방지하기 위해 클래스/컴포넌트 설계 가이드나 명세 단계에서 thread-safe 설계를 강제하는 편인가요?아니면 설계 때보단 코드 리뷰나 테스트 중 문제 발견 후 사후적으로 수정·보완하는 프로세스를 거치나요?

실제로 실행을 못해보는환경이라서 질문하는건데,JobLauncher를 활용한 REST API 구현의 예제같은경우 컨트롤러 하나를 생략없이 다 표현한거같은데 jobRegistry 는 di받지않았는데 어떻게 실행하는거임?빼먹은건가? job = jobRegistry.getJob(jobName);

TransactionManager 분리에 대해서 이해가 잘 가지 않는게 있어. 실제 운영 환경에서는 배치와 비즈니스 데이터 DB를 분리하는게 필수라고 했잖아?근데 이 분리의 단위가 배치용 메타데이터 저장만 분리를 하는게 맞는거야? 현재 사이드 프로젝트에서 멀티모듈 구조에 (MSA는 아님) API 모듈과 배치 모듈을 따로 분리한 상태야.유저 데이터에서 생일을 뽑아서 내일 생일인 유저에게 FCM 을 발송하는 배치를 만드는데,이때 만들어준 예제처럼 @BatchDataSource와 비즈니스 로직용 @Primary DataSource를 분리하게 되면,API 모듈용 DB Connnection을 배치에서도 똑같이 갖다 쓰는거 아니야 ?? 즉, 배치에서 API 쪽 커넥션을 가져다 써서 배치가 돌 때 커넥션이 고갈날 수 있지 않을까? 라는 생각이 들었어지금 이해한 바로는 @BatchDataSource, @BatchTransactionManager를 분리하고 주입해줘도 Reader -> Processor -> Writer 에는 @Primary 걸 쓰는것 같은데 맞아 ?나는 DB 분리와 함께, 비즈니스 로직에 대한 커넥션, 트랜잭션도 배치용으로 분리하고 싶은데 이럴땐 어떻게 해야해?특히나 배치에서도 JpaTransactionManager를 쓰고 싶은 경우에는 어떻게 해야해 ?원하는 바는, API 처리용 DB 커넥션은 커넥션대로 있고, 배치 메타데이터용 커넥션 따로, 배치에서 라이브 DB에서 유저 데이터를 가져오는 커넥션 따로 구성하고 싶어 (배치가 API 모듈 에 영향을 주지 않았으면 해서,,,) 혹시 내가 강의를 제대로 이해를 못한거라면 알려줘

킬구형 강의 자료 중간에 이상한 문구 발견해서 제보해강의 회차: 5장. 작전4: Flow - 배치의 흐름을 지배하라 (분기점에서 생사를 쥐락펴락하라 ☠🏴‍☠)이상한 문장: 즉, Spring Batch의 암시적 전환 규칙 대상에서 제외된다는 뜻이다.재시도Claude는 실수를 할 수 있습니다. 응답을 반드시 다시 확인해 주세요.강의 자료 중간에 LLM에서 가져온 내용을 잘못 편집한 것 같아.

안녕하세요 코틀린으로 현재 강의를 수강하고 있는 수강생입니다. 현재 자바로 작성된 코드를 보고 설명과 함께 어떤 이유로 이런 코드를 작성한 것인지 생각하며, 코틀린으로 이 개념을 적용하면 어떻게 작성할 수 있을지 DDD와 클린 아키텍처를 코틀린 문법 활용하여 구상하는 연습 중입니다. 현재 Member 도메인 코드 개선 강의에서 value class 적용하여 필드의 값이 바뀌는 문제(email자리에 nickname이 오더라도 같은 String이라 컴파일 에러가 안 남)를 해결하려 시도했습니다 package org.example.splearn.domain @JvmInline value class Email( val value: String, ) @JvmInline value class Nickname( val value: String, ) @JvmInline value class PasswordHash( val value: String, ) class Member private constructor( val email: Email, var nickname: Nickname, var passwordHash: PasswordHash, var status: MemberStatus, ) { fun activate() { check(status == MemberStatus.PENDING) { "회원이 PENDING 상태가 아닙니다" } this.status = MemberStatus.ACTIVATE } fun deactivate() { check(status == MemberStatus.ACTIVATE) { "회원이 ACTIVE 상태가 아닙니다" } this.status = MemberStatus.DEACTIVATED } fun verifyPassword( password: String, passwordEncoder: PasswordEncoder, ): Boolean = passwordEncoder.matches(password, this.passwordHash.value) fun changeNickname(nickname: String) { this.nickname = Nickname(nickname) } fun changePassword( password: String, passwordEncoder: PasswordEncoder, ) { this.passwordHash = PasswordHash(passwordEncoder.encode(password)) } fun isActive(): Boolean = this.status == MemberStatus.ACTIVATE companion object { fun create( memberCreateRequest: MemberCreateRequest, passwordEncoder: PasswordEncoder, ): Member = Member( email = memberCreateRequest.email, nickname = memberCreateRequest.nickname, passwordHash = PasswordHash( passwordEncoder.encode(memberCreateRequest.password.value), ), status = MemberStatus.PENDING, ) } } 강의대에서는 static 메소드인 of에서 MemberCreateRequest를 파라미터로 사옹하고 있습니다. 코틀린이라 companion object를 사용했구요 그러던 중 "헥사고날 아키텍처의 특성을 고려하면 의존성 외부 로직인 dto가 내부로 향해야 하고 따라서 도메인이 dto에 의존하는 것이 괜찮을까" 하는 의문이 들었습니다. companion object { fun create( email: Email, nickname: Nickname, password: String, passwordEncoder: PasswordEncoder, ): Member = Member( email = email, nickname = nickname, passwordHash = PasswordHash( passwordEncoder.encode(password), ), status = MemberStatus.PENDING, ) }그래서 코드를 수정해 보면 이런 식으로 수정해 볼 수 있을 것 같습니다. 이에 대해서 토비님 의견이 어떠신지 여쭙고 싶습니다