안녕하세요, 첫 질문입니다. 14강 외부 API 연동 - Spock 적용 10분 30초 경에 given 뒤 and 추가로 검증을 할 수가 있게 된다고 하셨는데 given 뒤 and 에는 검증 기능이 없는 것 아닐까요? old() 를 사용하거나 expect 를 사용하라는 얘기가 있는데 확인해 주실 수 있나요? 좋은 강의 감사합니다!
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] public Member save() 메서드에서 파라미터로 전달받은 member 인스턴스의 필드값을 DB에 저장하는 구조인데, 참조로 전달되니 반환하지 않아도 호출부의 member는 이미 동일한 객체를 가리키고 있잖아요? 그럼에도 마지막에 member를 리턴하는 이유가 따로 있을까요?
안녕하세요. 토비님 DIP와 관련하여 질문이 있습니다. "course" 컴포넌트 <- "curriculum" 컴포넌트는 단방향 의존성을 가져야하기 때문에, CurriculumValidator.class를 DIP를 통해 course 패키지로 옮긴 것을 이해하였습니다. 하지만, CurriculumValidator에서 던지는 예외인 InvalidCurriculumException.class는 "curriculum" 도메인에 속해 있습니다. 이것은 결국 양방향 의존성을 가지게 되는 것 아닌가요? 만약, 양방향 의존성이 맞다면, CurriculumValidator 인터페이스는 ValidationException을 던지도록 선언하고, CurriculumValidator인터페이스 구현체인 "CurriculumModifyService.class"는 "InvalidCurriculumException" 을 catch해서 ValidationException을 던지도록 수정하는 방법도 괜찮을까요?
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 강의에 나와있는대로 그대로 잘 프로젝트 생성하고 HelloSpringApplication.java 파일 열어서 옆에 재생버튼 눌렀는데 아래와 같이 오류가 뜨면서 실행이 안됩니다.. 왜그런걸까요..?ㅠㅠ
질문이라기 보다는 저같이 몇시간 버리시는 분 계실까 내용 공유드립니다. 도커 데스크탑 업데이트로 testcontainers 의존성 버전이 안맞은게 문제였습니다. 감사하게도 같은 문제로 다른분이 포스팅을 적어두셨더라구요. build.gradle 파일에서 testcontainers 의존성 -- 아래 처럼 변경 testImplementation 'org.testcontainers:testcontainers:2.0.5' testImplementation 'org.testcontainers:testcontainers-junit-jupiter:2.0.5' testImplementation 'org.testcontainers:testcontainers-mysql:2.0.5' ※ 최신버전은 Maven Rep 참고해주세요. 참고한 포스팅입니다. 도커 업데이트 이후 Testcontainers 테스트 실패 이슈 해결 기록 이슈 해결 외에도, 도커 버전에 따라 최소 API 버전 확인 할 수 있는 방법도 같이 기재되어있어 참고하기 좋은 것 같습니다.
안녕하세요. 강의를 열심히 들으면서 따라해보고 있는데 강의에서 나오는 네이버 API의 '검색 - 책' API 제공이 중단된 것 같습니다. 앞으로 강의가 계속 도서관련해서 나오는 것 같은데 어떻게 하면 좋을까요..? 관련 링크 첨부해드립니다. https://developers.naver.com/notice/article/32564 https://developers.naver.com/notice/article/32530
안녕하세요 토비님! 오랜만에 강의를 복습하다가 궁금한 점이 생겨 질문드립니다. 제가 헥사고날 아키텍처를 외부 서비스나 인프라 연동이 많은 시스템에서 주로 사용하는 구조 라고 이해하고 있었는데요. 강의에서는 비교적 작은 시스템에도 헥사고날 아키텍처를 적용하셔서, 제가 잘못 이해하고 있었던 건지 궁금합니다. 현재 작은 규모의 신규 프로젝트를 준비하고 있고, 도메인 모델 패턴과 풍부한 도메인 모델을 적용해보려고 합니다. 다만 외부 서비스 연동은 거의 없을 예정이라, 이런 경우에도 헥사고날 아키텍처를 적용하는 것이 적절한지, 아니면 오버엔지니어링이 될 수 있는지 판단이 잘 서지 않습니다. AI에게 물어봤을 때는 헥사고날 아키텍처 도입을 고려할 수 있는 기준으로 외부 연동의 수뿐만 아니라, 하나의 Port에 대해 구현체가 둘 이상 존재하거나 향후 교체 가능성이 있는지 도 이야기하더라고요. 강의에서 DDD와 헥사고날 아키텍처가 잘 맞는다고 설명해주셨는데, 결국 헥사고날 아키텍처를 선택할 때 외부 서비스 연동이 많은지 Port의 구현체가 여러 개이거나 교체 가능성이 있는지 도메인을 기술적인 의존성으로부터 분리할 필요가 큰지 같은 요소 중 무엇을 주요 기준으로 봐야 할까요? 작은 시스템이고 외부 연동도 거의 없다면 레이어드 아키텍처로 시작하는 것이 나은지, 아니면 풍부한 도메인 모델과 DDD를 적용한다는 이유만으로도 헥사고날 아키텍처를 선택할 충분한 이유가 있는지 궁금합니다.
안녕하세요! 6번 강의의 24:15 부분 즈음부터 설명하시는 장치 의존성에 대해 궁금한 점이 있어서 질문드리려고 합니다. 강의를 들으면 마치 "장치 의존성을 해결하기 위해 React.js와 같은 CSR 방식이 등장하였다."라고 이해하게 되는데, 그런 의도로 말씀하신게 맞는지 궁금합니다. 만약 그러한 의도로 말씀하신 것이 맞다면, 제가 알고 있는 내용과 많이 다른 것 같아 혼란스러워 질문을 작성하게 되었습니다. 제가 기존에 알고 있던 지식으로는, 다양한 화면의 장치에 대응하기 위해(즉, 장치 의존성을 해결하기 위해) "반응형 웹 디자인"이 등장한 것으로 알고 있는데요. HTML은 어떤 장치에서 받든 해당 파일을 구동하는 장치(구체적으로는 프로그램)에서 사용할 수 있게 결국 파싱이 되니까(Ex. DOM 생성) 장치에 의존하지 않는 것 아닌가요? 화면의 크기마다 달라지는 UI를 제어하기 위한 방법으로는 CSS에서의 반응형 웹 디자인으로 알고 있었는데요.. React.js와 같은 CSR이 등장하게 된 배경은 다양한 화면에 맞게 알맞은 UI를 보여주려고 한다기보다는, 웹 서버로 보내는 요청을 획기적으로 줄여(클라이언트의 브라우저에서 JS를 이용해 직접 index.html에서 필요한 요소(컴포넌트)를 리렌더링하므로) 웹 서버가 SSR 방식으로 설계되었을 때보다 더 적은 부하를 맡게 되고, 클라이언트 입장에서는 부드러운 화면전환을 경험할 수 있게 하기 위함으로 알고 있는데요. CSR 방식 자체가 장치 의존성을 해결할 수 있는 것이라면 그 이유가 무엇인지 궁금합니다!
평소에 인터페이스와 구현체를 만들때 테스트를 어디에 만드는게 맞을까란 고민을 했었는데, 마침 토비님이 강의에서 언급해주셔서 너무 반가웠는데요. 테스트는 인터페이스에 만들라는 말씀 잘 이해했습니다. 스펙을 테스트하기에 인터페이스를 대상으로 테스트를 만들어야하는것도 이해를 했는데요. 구현체가 2개 이상이 되면 어떻게 하시는지 궁금합니다. 각 구현체들이 스펙을 준수하는지 테스트 코드를 작성해야할텐데 인터페이스를 대상으로 테스트를 작성하면 구현체가 1개일땐 문제가 없는데 2개 이상일땐 좀 난감해지더라고요.
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) --> 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) --> 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) --> 예 [질문 내용] 현재 강의를 듣고 시작하기 위해 초기 Spring Boot를 설정 해야 할 것 같아 궁금한 사항이 있어 질문을 드립니다. 현재 제 자바 버전은 21과 윈도우 환경에서 사용하고 있으며 인텔리제이를 사용하고 있습니다. 영한 선생님의 강의 pdf를 보면요, start.spring.io 에 접속 후 보면 프로젝트 선택 중 Spring Boot 3.x.x를 선택하라고 나와있는데요, 현재 제가 접속할 시에는 전부 4버전들만을 선택 할 수 있게 되어 있는데요, 일단 pdf 교과서에는 스프링부트 3.0이상, JDK 17이상을 사용해야 한다고 써있기에 그냥 스프링 부트 4.1.0 선택 하고 현재 자바 21버전을 사용 하면 앞으로 강의를 진행할 시 결과물들이 영한님 화면과 완전 똑같이 진행이 가능할까요? 아니라면요, 꼭 스프링 부트 3.2라고 명시되어 있기에 해당 버전을 선택해야 하나요? 그런데 문제는 스프링 부트 3.2를 사용해야 한다면 start.spring.io 에서 4버전들이 아닌 3.2버전을 찾아서 선택해야 하는데요, 어디를 찾아봐도 3.x.x 클릭 할 수 있는 곳은 없는데요, 어떻게 셋팅을 해야하나요? 참고 해서 셋팅 할 수 있는 메뉴얼도 알려주시면 감사하겠습니다.답변을 기다리겠습니다.
안녕하세요. 강의 잘 듣고있습니다. 오늘 수강한 "엔티티 식별자와 JPA 엔티티" 에서 JPA 엔티티로 만들었다고해서 달라진게 없다 라고 표현하셨는데요. 애노테이션을 붙여서 컴파일 단계의 의존성은 생겼지만 해당 클래스가 다른 기술적 종속이 생긴건 아니라고 말씀하신거에 질문이 있습니다. 일단 애노테이션을 붙인 것을 용인할 수 있다는건 이해했고, 저도 동의합니다. 그런데 JPA 엔티티가 됨으로써 해당 클래스는 final 로 만들 수 없고, 생성자도 기술적 요구사항에 의해 최소 protected 로 공개할 수 밖에 없는데요. 이번 강의에서도 기존 의도는 private 이었지만 기술을 도입함으로써 애노테이션을 붙이는 것 이상의 작업이 있었습니다(생성자의 접근 수준 변경). 정말 애노테이션만 붙이고 아무것도 하지 않았다면 납득할 수 있지만 애노테이션 외에 다른 변경이 발생했는데도 기술적 종속이 없다고 볼 수 있을까요? 이정도 수준의 변경과 의존은 트레이드오프로 용인할 수 있다고 생각하면 할수는 있지만 엄밀히 따진다면 객체 설계에 영향을 줬다고 생각하는데, 어떻게 생각하시는지 궁금합니다.
아직은 어색하고 서먹서먹하니 존댓말로 질문드립니다. 인프피니까 이해좀.. 1장. 작전1: 바이너리 초이스 - 스프링 배치의 두 가지 스텝 유형 요걸 지금 읽고 있는데 중간에 이런 내용이 있습니다. [시스템 주의] 예시와 같이 ResourcelessTransactionManager 인스턴스를 직접 생성해 tasklet() 메서드에 전달해도 되지만 애플리케이션 내의 여러 스텝에서 재사용할 수 있도록 별도의 Bean으로 정의하고 싶을 수도 있다. 그러나 PlatformTransactionManager 빈을 직접 정의할 땐 주의가 필요하다. 뭔가 문장이 좀 어색한데 처음엔 ResourcelessTransactionManager인스턴스를 Bean으로 정의하고 싶을 수 있다고 하시고는 갑자기 PlatformTransactionManager 빈을 직접 정의할 땐 주의가 필요하다고 하셨습니다. 이게 말 그대로 PlatformTransactionManager 빈을 직접 정의할 때 주의 하라는 뜻인건지, 아니면 ResourcelessTransactionManager 빈을 직접 정의할 때 주의 하라는 뜻인건지, 아니면 둘 다 빈을 집적 정의할 때 주의 하라는 뜻인지 조금 헷갈립니당 뒤에 따라오는 문장들을 읽어보면 아마도 PlatformTransactionManager 빈을 직접 정의할 때 주의하라는 말 같은데 그럼 ResourcelessTransactionManager 빈을 직접 정의 할 때의 주의사항은 없나용?
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 스프링 빈 등록 방법 중 @Autowired를 사용해 자동으로 등록하는 방법과 자바 코드로 직접 스프링 빈을 등록하는 방법 두 가지를 모두 알아야 한다고 하셨는데, 그 이유가 무엇인가요?