토비님의 의견에 동의합니다. 화면에서 필드 하나 필요하다는 수정사항을 처리하기 위해 Presentation 레이어 이외의 클래스들을 수정하고 싶진 않아요. 그럼에도 불구하고 현업에선 정말 수많은 이유를 들어서 DTO로 반환하는 걸 유지하려고 합니다. 별도의 관심사를 끌어안게 되면서 애플리케이션 레이어의 테스트 코드 작성이 까다로워지고, 그로 인해 안정성이 하나씩 무너지고 균열이 생기기 시작하는 지점이 이곳이지 않을까 싶어요. 어찌보면 강의를 들을까 고민하던 때에 가장 매력있게 보였던 챕터였고, 무언가 해답을 얻을 수 있을까 했지만 여전히 뭔가 용기가 생기진 않는 것 같습니다. 물론 그것이 토비님 탓은 아니죠. 훌륭한 가르침이지만, 단지 이것을 제 현장에 전파할 때 발생할 어려움에 벌써 머리가 아파지는 것.. 그 뿐입니다. 질문은 아니고 그저 넋두리였습니다. 나머지 강의 마저 잘 들어보겠습니다. 감사합니다
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] 여기에 질문 내용을 남겨주세요. 안녕하세요, 영한님! JPA 활용2 강의 감사한 마음으로 잘 보고 있습니다. @PostConstruct는 빈이 생성되고 의존성 주입이 모두 끝난 직후에 자동으로 실행되는 메서드로 프록시 생성 이전에 실행되기 때문에 @Transactional과 함께 사용할 수 없어, init() 메서드에서 두 애노테이션(@PostConstruct, @Transactional)을 함께 작성할 수 없는 걸까요? GPT 답변을 참고한 후 질문 드립니다!
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예 [질문 내용] 여기에 질문 내용을 남겨주세요. 강의 3분 정도 쯤에 나오는 createOrder 메서드 생성 시 정적 팩토리 메소드를 사용하는 이유가 궁금해 여러 질문과 답을 읽어보았는데요. 의미 있는 메서드 이름 부여, 객체 생성 불필요 등 여러 장점이 있다는 것을 알았습니다. 그렇다면 대부분 생성자보단 정적 팩토리 메소드로 객체를 생성하는 것이 좋은 건가요? 아니면 객체 생성 시 연관관계 설정이나 복잡한 로직이 있을 때만 정적 팩토리 메소드로 만들어주는 게 좋은 건가요? 정적 팩토리 메소드 사용 이유에 어떤 기준이 있는 건지, 아님 보통 관례로 이렇게 사용하는 건지 궁금합니다!
POST API 첫번째 강의에서 main.py의 52번 줄에 request를 dict() 형식으로 꼭 맞춰 주어야하나요?? 출력은 request >> id=4 contents='aaa' is_done=True request.dict() >> {'id': 4, 'contents': 'aaaa', 'is_done': True} 이렇게 되는데, 그냥 request 만 써도 swagger UI에서 보았을 땐 똑같이 dict 형식으로 들어오더라구요. 궁금해서 문의드립니다.
맹목적인 파라미터의 숫자가 아닌 보통 함축적 정보를 전달하기 위해 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 계층이 바뀌더라도 핵심 비즈니스 로직은 변하지 않아야 한다 (계층형), 는 점에서 둘의 지향점은 같다고 느낍니다. 혹시 제가 놓치고 있는 중요한 관점이 있을까요? 토비님께서는 이 두 아키텍처를 어떻게 구분하시고, 어떤 기준을 중요하게 보시는지 궁금합니다.
안녕하세요. 김판다 강사님을 보조하는 이조교 입니다. 저는 강사님 개인 메일로 도착한 질문들을 정리해, 다른 수강생분들께도 도움이 되도록 질문 게시판에 깔끔하게 편집해 올리고 있습니다. 개인 메일( pandakimt@gmail.com )로 질문하셔도, 강사님이 활발히 답변해드립니다. 제목: 구글 코랩에서는 셀마다 변수 값을 다시 정의해야 하나요? 구글 코랩에서는 셀마다 변수 값을 다시 정의해야 하나요? 아니면 첫 번째 셀에서 x = 10 이라고 하면, 두 번째 셀에서도 x 를 그대로 쓸 수 있나요?
[리뉴얼] 처음하는 파이썬 데이터 분석 (쉽게! 전처리, pandas, 시각화 전과정 익히기) [데이터분석/과학 Part1]
현재 강의 수강 중에 참고 엑셀 파일들을 활용하여 실습을 진행할려고하는데 강의 7에서 다운 받은 자료에서 COVID-19-master 관련 등 자료들이 누락된거 같아서 혹시 별도 첨부파일이 있는지 아니면 강의 28부터 실습에 사용하는 참고 자료들을 별도로 받을 수 있을까요 ?
[질문 템플릿] 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 와 결합했을 때, 어떻게 구성하면 좋을지 많은 생각이 들고 또한 현업에서 비슷한 고민을 하고 있어서 토비님의 생각이 궁금해 질문을 남기게 되었습니다. 감사합니다.
