[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] 안녕하세요 영한님 강의 듣다가 Result 클래스를 써야한다고 언급해주셨는데요, 해당 클래스 관련 질문 답변을 봤는데 https://www.inflearn.com/community/questions/442871/result-%ED%81%B4%EB%9E%98%EC%8A%A4-%EA%B4%80%EB%A0%A8-%EC%A7%88%EB%AC%B8%EC%9E%85%EB%8B%88%EB%8B%A4?focusComment=168228 @GetMapping("/{boardId}") public ResponseEntity<BoardResponse> getBoard(@PathVariable("boardId") Long boardId) { return ResponseEntity.ok(boardService.getBoard(boardId)); } 이런식으로 ResponseEntity 감싸서 DTO를 반환하는것과 Result 클래스가 같은 맥락으로 응답을 추상화한다고 생각하면 될까요? 감사합니다 :)
인사말 안녕하세요. 질 높은 강의를 제공해주셔서 너무 감사하다는 말씀드립니다. 아직 강의를 모두 본 것은 아니어서, 제가 질문드리고자 하는 내용이 강의에 포함이 되어있을지 모르겠습니다만.. 궁금한 내용을 질문드립니다. 질문 많은 모놀리식 프로젝트에서는 Spring Web + Spring Data JPA를 의존성을 주입하고 개발을 하고 저 또한 이러한 방식의 개발을 경험해왔습니다. Spring Data JPA와 Spring Web은 동기방식으로 동작하게 되는데, MSA의 독립 모듈을 만들 때 해당 의존성들을 사용하는 것이 바람직한지 모르겠습니다. 강의의 내용처럼 하나의 서비스는 독립적으로 구성된 수십개에서 수백개의 독립된 애플리케이션으로 동작을 하게 될 것인데요. 상황에 따라 다르기는 하겠지만 Spring Web과 Spring Data JPA를 사용하는 독립된 애플리케이션이 있게 된다면 이쪽에서 병목이 일어나 엄청난 성능 이슈가 발생할 것으로 생각이듭니다. 이와 같은 고민을 갖고 GPT한테 물어보니 WebFlux와 R2DBC를 사용하여 모두 비동기적으로 만드는 것이 권장되는 사항이라고 하는데 이 답변이 맞을까요? MSA를 구성한다고 한들, 모놀리식보다 성능상 좋지가 않으면 MSA로 구축할 필요성이 없을 것인데, 제가 우려하는 성능상의 심각한 문제 / 병목현상을 예방하기 위한 설계를 어떻게 해야하는지 너무 궁금합니다. 추가적으로는 Speing web이나 Spring Data Jpa가 MSA에거 어느 점에 필요하게 됭까요? 성능 관점에서 도무지 필요성을 느끼지 못하고있습니다. 질문이 너무 두서가 없는데... 질문 내용이 강사님께 잘 전달되었길 바랍니다..!
토비님의 의견에 동의합니다. 화면에서 필드 하나 필요하다는 수정사항을 처리하기 위해 Presentation 레이어 이외의 클래스들을 수정하고 싶진 않아요. 그럼에도 불구하고 현업에선 정말 수많은 이유를 들어서 DTO로 반환하는 걸 유지하려고 합니다. 별도의 관심사를 끌어안게 되면서 애플리케이션 레이어의 테스트 코드 작성이 까다로워지고, 그로 인해 안정성이 하나씩 무너지고 균열이 생기기 시작하는 지점이 이곳이지 않을까 싶어요. 어찌보면 강의를 들을까 고민하던 때에 가장 매력있게 보였던 챕터였고, 무언가 해답을 얻을 수 있을까 했지만 여전히 뭔가 용기가 생기진 않는 것 같습니다. 물론 그것이 토비님 탓은 아니죠. 훌륭한 가르침이지만, 단지 이것을 제 현장에 전파할 때 발생할 어려움에 벌써 머리가 아파지는 것.. 그 뿐입니다. 질문은 아니고 그저 넋두리였습니다. 나머지 강의 마저 잘 들어보겠습니다. 감사합니다
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] 여기에 질문 내용을 남겨주세요. 안녕하세요, 영한님! JPA 활용2 강의 감사한 마음으로 잘 보고 있습니다. @PostConstruct는 빈이 생성되고 의존성 주입이 모두 끝난 직후에 자동으로 실행되는 메서드로 프록시 생성 이전에 실행되기 때문에 @Transactional과 함께 사용할 수 없어, init() 메서드에서 두 애노테이션(@PostConstruct, @Transactional)을 함께 작성할 수 없는 걸까요? GPT 답변을 참고한 후 질문 드립니다!
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예 [질문 내용] 여기에 질문 내용을 남겨주세요. 강의 3분 정도 쯤에 나오는 createOrder 메서드 생성 시 정적 팩토리 메소드를 사용하는 이유가 궁금해 여러 질문과 답을 읽어보았는데요. 의미 있는 메서드 이름 부여, 객체 생성 불필요 등 여러 장점이 있다는 것을 알았습니다. 그렇다면 대부분 생성자보단 정적 팩토리 메소드로 객체를 생성하는 것이 좋은 건가요? 아니면 객체 생성 시 연관관계 설정이나 복잡한 로직이 있을 때만 정적 팩토리 메소드로 만들어주는 게 좋은 건가요? 정적 팩토리 메소드 사용 이유에 어떤 기준이 있는 건지, 아님 보통 관례로 이렇게 사용하는 건지 궁금합니다!
맹목적인 파라미터의 숫자가 아닌 보통 함축적 정보를 전달하기 위해 DTO, 즉 파라미터 오브젝트를 사용해서 전달하는 방식은 워낙 간결한 방식이라 저도 선호도가 높긴 합니다. 하지만 엔티티의 영역에서 DTO와 유사한 레코드 형식의 매개변수를 전달 받는 방식은 어느 정도 엔티티의 순수성이 침해 받는 방식이 아닌가 생각이 들어서요. 실제로 작성하신 코드를 봤을 때 그런 순수성 집착 보다 휴먼 에러를 사전에 방지하는 접근 방식이라 매우 적절한 트레이드 오프라고 생각이 들기도 합니다. 이 부분에 대해서 개인적인 궁금증이 생겨서 질의 드립니다. 아직 강의를 다 본 상황이 아니라서 이런 질문을 하는 게 맞는지 작성하는 지금 이 순간 조차 고민이 되지만, 실제로 제가 생각하던 방식과의 거리감이 느껴져서 질문을 남겨봅니다.
안녕하세요 토비님! 항상 강의를 통해 새로운 시야를 얻는 것 같아 감사하게 듣고 있습니다! 강의를 수강하던 중 궁금한 점이 하나 생겨 질문 드립니다. 우선 현재 Section7, 39강까지 수강한 상태입니다. 도메인 규칙 상으로 프로필 주소가 제거 가능하다고 정해졌고, 이는 코드로 상세히 표현되었다고 생각했습니다. 하지만 " 프로필 주소는 제거할 수 있다 "라는 규칙을 적용해 memberA가 프로필 주소를 빈 문자열 형태로 변경한다면, memberB의 경우 동일하게 빈 문자열을 저장할 수 없으니 프로필 주소를 제거할 수 없는 것 아닌가라는 생각이 들었습니다. 그래서 기존 Github에 공개된 코드 테스트에서 실험을 진행했습니다. (제 코드는 차이가 있을 수 있어서 공개된 자료를 이용했습니다.) MemberRegisterTest#updateInfoFail 에 아래와 같이 테스트를 추가해 보니 entitymanager.flush() 부분에서 Unique index or primary key violation 이 발생했습니다. 제 생각에는 도메인 규칙을 변경하거나, profile_address의 값이 빈 문자열일 경우 NULL을 저장하도록 로직을 변경해야한다고 생각합니다. 혹시 제가 놓친 부분이 있는지, 토비님의 의견은 어떠신지 궁금합니다. 항상 감사하게 수강하고 있습니다!
최근에 제가 고민했던 부분의 토비님의 의견이 궁금해서 질문드립니다. “계층형 아키텍처와 헥사고날 아키텍처는 정말 본질적으로 다른 걸까?” 예를 들어, 계층형 아키텍처에서도 인터페이스를 통해 상위 계층이 하위 계층을 의존하도록 설계하면 DIP(Dependency Inversion Principle)를 지킬 수 있습니다. 그렇게 하면 헥사고날 아키텍처가 지향하는 의존성 역전 과 사실상 동일한 구조가 만들어지지 않을까요? 그렇다면 DIP를 잘 구현한 계층형 아키텍처는 헥사고날 아키텍처와 다르지 않다 고도 볼 수 있을 것 같습니다. 이 생각대로라면, 우리가 그동안 “계층형 아키텍처”라고 부르며 개발하던 많은 구조들이 사실상 헥사고날 아키텍처였던 것 아닌가? 라는 생각도 들었습니다. 만약 두 아키텍처가 여전히 다르다고 본다면, 그 차이는 폴더 구조나 패키지 구성 방식 처럼 물리적인 형태에서 오는 걸까요? 하지만 두 아키텍처 모두 논리적이고 추상적인 설계 철학 을 이야기하는 것인데, 물리적 구조로만 구분하는 건 이상하다고 느껴집니다. 결국 저는, 잘 설계된 아키텍처라면 헥사고날이든 계층형이든 최종 목표는 동일하다 , 라는 생각이 들었습니다. 즉, SRP(Single Responsibility Principle) 를 지키고, 외부 기술의 변화가 도메인에 영향을 주지 않아야 하며 (헥사고날), persistence 계층이 바뀌더라도 핵심 비즈니스 로직은 변하지 않아야 한다 (계층형), 는 점에서 둘의 지향점은 같다고 느낍니다. 혹시 제가 놓치고 있는 중요한 관점이 있을까요? 토비님께서는 이 두 아키텍처를 어떻게 구분하시고, 어떤 기준을 중요하게 보시는지 궁금합니다.
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] @Test @DisplayName("상품주문_재고수량초과") public void orderOverStock() throws Exception { //given Member member = createMember(); Item item = createBook("시골 JPA", 10000, 10); int orderCount = 11; //when //then Assertions.assertThrows(NotEnoughStockException.class, () -> orderService.order(member.getId(), item.getId(), orderCount)); } 촬영 시점과 달리 assertThrows로 변경되며 given, when, then이 참 모호해진 것 같습니다. 제가 이해한 바에 따르면, 변수 설정은 given, 메서드 호출은 when, 결과와 검증은 then에서 수행하는 것 같은데 위 코드와 같은 경우는 어떻게 분리해야 할까요? when은 위와같이 비워두는게 맞을까요?
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 14:26을 보시면, createOrderItem에서 모든 필드에 대해 세터를 호출하여 일일히 값을 주입합니다. 다양한 파라미터를 사용하는 경우의 수에 대해 각각 생성자를 선언해두면 가독성이 상승하여 추후 유지보수에도 더 편리할것 같은데, 이렇게 사용하는 이유가 있나요? 스프링 강의만 수강하고 야생형 코스를 막 시작한 입장에서, 제가 기억하는 생성자 관련 원칙은 다음과 같습니다. 아무 생성자도 없다면 기본 생성자가 생성된다. JPA는 리플렉션을 통해 코드를 생성하기에 기본 생성자는 반드시 필요하므로, 필요하면 명시하여 생성한다. DI를 위해서 @RequiredArgsConstructor를 이용하여 final 필드를 사용하는 생성자를 생성하고, 주입받는 방식을 권장한다. 생성자는 최소화하라는 다른 원칙이 존재하는 것인가요?
안녕하세요 토비님, 우선 강의를 통해 제가 알고 있던 헥사고날 과 DDD(도메인 주도 설계) 에 대해 다시 한번 깊이 생각해볼 수 있는 소중한 경험이 되었습니다. 좋은 강의 만들어주셔서 정말 감사합니다. 토비님께서 생각하시는 헥사고날에, DDD 과 멀티 모듈 의 바람직한 설계에 대해 궁금해서 질문을 남기게 되었습니다. 여기서의 멀티 모듈은 우선 MSA 를 제외하고 순수 멀티 모듈을 통해 시스템을 설계를 한다는 것을 전제하고 있습니다. 가장 흔하게 보이는 멀티 모듈 구성의 패턴은 Storage (JPA), External (외부 Dependency), N 개의 서비스에 해당하는 Web Server 모듈 & 기타 등이 있는 것 같은데요. 멀티 모듈을 현 강의에서 보여주고 말씀해주시는 헥사고날과 DDD 와 결합했을 때, 어떻게 구성하면 좋을지 많은 생각이 들고 또한 현업에서 비슷한 고민을 하고 있어서 토비님의 생각이 궁금해 질문을 남기게 되었습니다. 감사합니다.
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 17:13경 하신 설정이 최신 intellij와 스프링부트에서도 필요한 설정인가요? 어떤 기능을 하는 설정인지 궁금합니다. 2025년 기준 인텔리제이에서 확인할 수 없어 여쭙습니다.
안녕하세요 토비님! 좋은 강의 정말 감사드립니다. @TestConfiguration 에 대한 설명을 해주신 부분 중에서 테스트 결과와 다른 부분이 있는 것 같아 확인차 질문 드립니다. <28. 회원 애플리케이션 서비스 테스트 (2)> 의 11:38에서 " @TestConfiguration 에 어떤 Bean을 정의하면 이게 우선이 되어 돌아갑니다." 라는 말씀을 해주셨는데요. 해당 말씀이 맞는지 테스트해 보기 위해, 현재의 강의 예제 코드에서 @TestConfiguration 이 붙은 클래스의 PasswordEncoder 를 정의한 Bean 메서드의 이름을 testPasswordEncoder로 변경하고 테스트를 돌려 보니 아래와 같은 오류가 발생하였습니다. ( EmailSender 의 경우 DummyEmailSender에 @FallBack 이 붙어 있어서 @TestConfiguration 의 EmailSender Bean 메서드의 이름을 다르게 구성하더라도 테스트는 정상적으로 동작합니다.) @TestConfiguration 이 정의되었다고 해서 우선순위로 동작하지는 않는 것으로 보이고, 기존 Bean의 적용 우선순위에 따라 @TestConfiguration 에서 정의한 메서드 이름과, 이를 사용하는 곳의 필드 이름이 동일한 경우 해당 Bean을 찾아서 동작하는 것으로 보였습니다. 혹시 제가 잘못 이해하고 있거나 보완이 필요한 부분이 있다면 편히 말씀 부탁드립니다. 확인 부탁드립니다. 감사합니다 :)
spring_cloud_gateway_requests_seconds_count{ httpMethod ="GET", httpStatusCode ="401", instance ="localhost:8000", job ="apigateway-service", outcome ="CLIENT_ERROR", routeId ="user-service", routeUri ="lb://USER-SERVICE", status ="UNAUTHORIZED"} 22 spring_cloud_gateway_requests_seconds_count{ httpMethod ="GET", httpStatusCode ="404", instance ="localhost:8000", job ="apigateway-service", outcome ="CLIENT_ERROR", routeId ="order-service", routeUri ="lb://ORDER-SERVICE", status ="NOT_FOUND"} 회원가입과 로그인만 하더라도 이러한 것들의 숫자가 올라가 총 요청 수 중 성공한 숫자가 매우 적습니다. chat gpt에서는 자동으로 health-check를 해서 그렇다라고는 하는데 정확히 어떤 것이 문제인지 잘 모르겠습니다.
