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

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

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

안녕하세요. 강의 잘 들었습니다.분산 시스템이 맞는지는 모르겠지만,, 다른 회사의 API들을 여러개 사용할때에 궁금증이 있어서 질문 드립니다.문제 상황은 아래와 같습니다.우리 쪽에서는 이미 사용자가 토큰 기반으로 인증된 상태이며,이 사용자의 요청을 대신해 외부(회사1, 회사2)의 API를 호출해야 하는 상황입니다.또한, 사용자가 버튼을 눌렀을 때 새 브라우저 창을 띄워 회사2의 웹 애플리케이션으로 이동해야 하는데,이때 로그인 과정을 생략하고 자동으로 접속(SSO) 되도록 만들고 싶습니다.질문 1⃣API 인증 전파 관련우리 서버가 회사1·2 서버로 요청을 보낼 때,상대 서버에서는 “이 요청이 실제 인증된 사용자로부터 온 것”임을 어떻게 검증하는 게 일반적인가요? 2⃣브라우저 SSO 관련새 탭을 열어 회사2 웹 서비스로 이동 시,재로그인 없이 자동으로 인증(Single Sign-On) 되게 하려면 어떤 방식이 많이 사용되나요?

안녕하세요, 개인적으로 궁금한 게 있어서 질문드립니다.요즘 React Router를 보면 SSR 프로젝트를 위한 프레임워크가 나오는 등, 서버 사이드 렌더링 환경을 지원하는 방향으로 발전하고 있는 것 같더라고요.그래서 문득 궁금해졌는데,요즘 시장에서는 CSR방식의 수요가 많이 줄어드는 추세인가요?아니면 여전히 CSR 중심의 프로젝트도 많은 편인가요?현재는 CSR 기반으로 개발하고 있는데, 앞으로의 흐름을 생각하면 SSR 관련 기술도 공부해야 할지 고민 중입니다.현업에서 체감하시는 부분이나 조언을 듣고 싶습니다

윈도우 버전 이슈로 로컬에 도커를 설치 못하는 상황인데요 (예전에도 설치 이슈있어서 해결하려다가 실패) 혹시 해결 방법 알고 계실까요?해결이 어려우면 깃허브 코드스페이스에서도 실습이 가능한 내용일까요   

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

안녕하세요. 주문 처리에 관련해서 질문 있습니다!!고민하다가 질문드려요 ㅠ!중복 주문을 해결하기 위해 주문 생성 API , 주문 처리 API를 나누는걸로 이해하고 있습니다.만약 쇼핑몰에서 사용자가 주문을 할때 주문 생성 API를 요청하고 결제처리 (PG사) 성공하면 주문 처리 API(재고차감 등등) 를 하는걸로 알고 있습니다.하지만 주문 생성 API에서 수량을 검증한다고 하더라도 결제를 완료하고 주문 처리를 할때 다른 사용자에 의해서 재고가 부족할수 있는 상황이 있다고 생각합니다.이럴때는 실무에서 어떻게 해결하는지가 궁금합니다!!!!비동기적으로 보상해준다고 하면 뭔가 사용자입장에서 결제까지 했는데 재고가 부족해서 주문처리가 실패하여 환불까지된다?.... 이게 좀 비효율적이라 생각해서요!!답변 부탁드립니당실무에서는 어떻게 사용하나요 ! 궁금해요ㅠㅁㅠ

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

http://localhost:5601/app/discover#/ 진입하면 현재 이렇게 나옵니다. 저기서 add integration 누르면 다음 화면처럼 나오는데.. 진행을 어떻게 해야될지 모르겠습니다.  

안녕하세요, 강의에서는 메시지 브로커용으로 redis를 사용하셨는데, redis 외에도 rabbitmq나 카프카 같은 것들도 사용되는 것으로 알고있습니다. 그 중에서 특별히 redis를 사용한 이유가 있는지 궁금합니다.그리고 무중단 배포 시 스프링 내장 브로커를 사용하면 서버 재실행 시 구독 정보가 초기화되기에 메시지 브로커를 도입하려고 하는데 이때는 셋 중에 어떤 것을 사용하면 좋을지 궁금합니다.

킬구형 강의 자료 중간에 이상한 문구 발견해서 제보해강의 회차: 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, ) }그래서 코드를 수정해 보면 이런 식으로 수정해 볼 수 있을 것 같습니다. 이에 대해서 토비님 의견이 어떠신지 여쭙고 싶습니다

common pool을 사용하지 않도록 thread pool을 설정 해야 된다고 주의사항을 적어주셨는데 그 이유는 무엇인가요?그리고 둘의 차이는 onPool-worker-3, pool-1-thread-8 이라고 알려주셨는데 차이가 이거밖에 없는건가요?

안녕하세요, 강사님! Spring Boot TDD 강의 정말 잘 듣고 있습니다. 강의 내용 중 궁금한 점이 생겨 질문드립니다.보통 Spring에서 개발할 때 Controller-Service-Repository 구조의 레이어드 아키텍처를 많이 사용하는데요, 강의에서는 컨트롤러가 직접 리포지토리의 save 같은 메서드를 호출하면서 비즈니스 로직을 처리하는 경우가 있는 것 같습니다.혹시 이것이 강의의 핵심 내용에 집중하기 위해 코드를 단순화하신 것인지, 아니면 강사님께서 실제로 선호하시는 개발 스타일이신지 궁금합니다. 만약 후자라면 어떤 장점이 있는지 그 이유에 대한 의견을 여쭙고 싶습니다.더불어, "TDD를 잘하려면 인터페이스를 많이 사용해야 한다"는 것이 일종의 오해라는 말씀에 크게 공감했습니다. 그런데 왜 개발자들 사이에서 이런 오해가 생겨나게 된 것인지 그 배경이 궁금합니다.마지막으로 추후에 비즈니스가 복잡해지면 테스트가 깨졌을 때 어디가 문제인지 파악이 어려울 것 같은데요 이에 따른 문제를 어떻게 해결하시나요? 단위테스트를 추가로 작성하시는지도 궁금합니다.

WebSocket 연결이 처음 http요청으로 시작하기 때문에 필터 체인이 요청을 가로챈다.따라서 /connect를 permitAll()로 풀어줘야 400에러가 안난다.  로 이해했는데 맞을까요?

안녕하세요, 강사님. TDD 관련 강의 항상 잘 듣고 있습니다.강의 내용을 따라 실습을 진행하던 중, 테스트 격리 전략에 대해 궁금한 점이 생겨 질문 남깁니다. # 강의에서 다뤄주신 상황강의에서처럼 여러 테스트 메서드에서 동일한 이메일 값을 사용하니, 테스트 클래스 전체를 실행했을 때 JPA의 유니크 제약 조건 위반 에러가 발생했습니다. 이로 인해 개별 테스트는 성공하지만 전체 테스트는 실패하는 상황에서 궁금증이 생겼습니다. # 제가 먼저 생각한 해결책: @Transactional을 이용한 롤백저는 강의를 들여면서 이 문제를 해결하기 위해, 각 테스트 메서드에 @Transactional 애너테이션을 붙여 테스트가 끝나면 자동으로 롤백시키는 방식을 먼저 떠올렸습니다. 이 방법으로 각 테스트가 독립적인 트랜잭션 내에서 실행되고, DB 상태를 다음 테스트에 영향을 주지 않는 상태로 유지할 수 있다고 생각했습니다. ##강사님의 방식(임의 데이터 generator)에 대한 질문##그런데 강사님께서는 강의에서 롤백 방식을 사용하지 않으시고, UUID 등을 활용해 매번 고유한 이메일 주소를 생성해주는 데이터 제너레이터 방식을 사용하셨습니다. 강의에서도@Transactional 을 성능 등 여러가지 이유로 인해 사용하지 않았다고 하셨는데요.@Transactional을 이용한 롤백 방식도 충분히 좋은 해결책이라고 생각했는데, 강사님께서 UUID 생성 방식을 선택하신 특별한 이유나 설계 철학이 궁금합니다.혹시 제가 생각한 롤백 방식에 비해 UUID 생성 방식이 갖는 실용적인 장점(ex. 롤백을 하지 않으니 디버깅의 용이성(?))이 있을까요? 두 방식의 장단점과 어떤 상황에서 어떤 전략을 선택하는 것이 실무에서 더 좋을지에 대한 강사님의 고견을 듣고 싶습니다. 감사합니다!

가령 다음과 같이 getExecutionContextSerializer() 메서드를 오버라이드하면g에 볼드처리안됨--원시적 침투 예제의 BatchConfig에서 DefaultBatchConfiguration 상속을 제거하고@EnableBatchProcessing을 추가하자. 다음과 같이 말이다.예제밑의 예제가 그냥 기존 DefaultBatchConfiguration 방식만 나와있음아마 기존과 수정을 두개 다 표시하는식으로 하고싶었을거같음--JobContext/StepContext: Late-Binding의 최종 무기고키룩형 JobContext/StepContext가 존재하면 배치 스코프가 활성화된 상태라는 것은 알겠어. 근데 이 JobContext/StepSontext 대체 어디에 써먹는거지? 단순히 활성화를 의미하는게전부인가?키룩형 -> 갈매기가 되고싶은 내면의 소리일수있음괜찮음 주변에 돌멩이 지망생도 있고 독수리 지망생,딸기우유 지망생도 있어서 이해할수있음

좋은 추석 보내고 계신가요?현재 코틀린으로 강의를 따라해 보고 있습니다. class Member private constructor( val email: String, var nickname: String, var passwordHash: String, 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) fun changeNickname(nickname: String) { this.nickname = nickname } fun changePassword(password: String) { this.passwordHash = password } companion object { fun create( email: String, nickname: String, password: String, passwordEncoder: PasswordEncoder, ): Member = Member( email, nickname, passwordEncoder.encode(password), MemberStatus.PENDING, ) } }이러한 식으로 작성하였는데 자바에서는 const로 선언한 객체나 변수가 아닌 이상 기본적으로 가변입니다. 그런데 코틀린에서는 val, var 키워드에 따라서 var로 선언해야 가변 타입이 됩니다. Member 도메인 모델 확장 챕터 수강하고 있는데 이 경우는 도메인에서 가변 속성을 미리 정의하고 해당 속성들을 var로 선언하는 것이 맞을지, 혹은 val을 통해 불변성을 확보하고 새 객체를 생성하여 변경을 처리하는 것이 적합할지 궁금합니다.코틀린에서 도메인 코드를 작성할 때 자바와 다른 문법&개념과 도메인 중심 설계가 종종 난해할 때가 있네요.

강의를 들으면서 내부 설계에 의존하는 테스트라는 것이 무엇인지 조금 헷갈려서 질문 드립니다. 강의 초반에는 테스트가 내부 설계에 의존해서는 안된다고 말씀 주셨습니다. 내부 설계에 의존하게 되면 테스트가 깨지는 등의 부작용이 발생할 수 있기 때문이라는 점도 함께 말씀 주셨는데, 이번 강의에서는 내부 설계에 의존해야 하는 케이스를 설명 해주셨습니다. 다만 왜 이런 케이스에는 내부 설계에 의존해야 하는지를 확실하게 이해를 하지 못했습니다. 조금 더 자세한 질문을 드리자면내부 설계의 의미내부 설계에 의존해야 하는 이유이 두가지를 잘 이해하지 못한 것 같습니다.내부 설계라는 것이 클라이언트가 실제로 사용하는, 외부로 공개된 인터페이스를 제외한 모든 부분을 말하는 것일까요? 이번 강의에서 내부 설계에 의존해야 하는 이유는클라이언트는 어떤 방식으로 암호화를 하는지 알 필요가 없다.하지만 현재 공개된 인터페이스로는 실제 비밀번호가 평문으로 저장이 되었는지, 아니면 정말 암호화가 이루어져 저징이 되었는지를 확인할 수 있는 방법이 없다.그러므로 실제 암호화 로직을 테스트 해야한다 (내부 설계에 의존해야 한다)정도로 이해했습니다만 제가 맞게 이해한 것인지 감이 오질 않습니다. 요약하자면내부 설계란 외부로 드러난 인터페이스 외적인 것들을 말하는 것인지왜 내부 설계를 의존해야만 하는 상황이 발생하는지정도일 것 같습니다. 감사합니다.