xml관련 설정강의자료로 남겨주신다고 했는데 어디서 찾을 수 있나요?

orm.xml unique-constraint 설정 부분 설명해주신 부분에서 인덱스로서 성능을 위해서, 데이터 중복저장 문제를 위해서 설정을하면 좋다고 말씀해주셨는데요<index unique="true">설정의 차이점이 뭔지 잘모르겠습니다

안녕하세요. 토비님, 강의 잘 듣고 있습니다. 🙂오늘은 강의 내용에서 좀 굉장히 의외인 부분을 발견해서 질문드립니다.강의 #41. MemberApi와 웹 단위 테스트 에서 MemberRegisterRequest 가 domain 레이어에서 정의했던 클래스임에도, @RequestBody 파라미터 그대로 쓰셨는데, 이 부분이 많이 의외고 우려가 되었습니다.저렇게 하면 MemberRegisterRequest 클래스의 코드 변경이 api 스펙 변경을 의미하는지가 코드리뷰 상에서 쉽게 보이지 않고 숨겨질 수 있다는 염려가 됩니다.실제로 MemberRegisterRequest 에 필드를 추가해서 PR 을 올리면 코드리뷰어가 봤을 때 domain 레이어의 특정 모델에 필드가 추가됐을 뿐인 작은 변경으로 보일 것입니다. 그래서 그것이 어느어느 API 의 스펙에 영향을 주는지 알기가 너무 어려울 것 같습니다.그래서 저는 API 의 스펙이 되는 Request, Response DTO 의 경우 반드시 클래스를 별도로 분리해야한다고 생각합니다.API 스펙은 server 마음대로 변경할 수 있는 서버만의 코드가 아니라 client 와의 계약 문서라고 보기 때문입니다.그래서 Request/Response 같이 백앤드 엔지니어가 함부로 변경할 수 없는 영역과 맘대로 변경 가능한 영역을 분리해서, 어플리케이션과 도메인 로직의 변화가 API 스펙 변경으로 인한 장애 걱정으로 이어지지 않게 하는 것이 중요하다고 생각합니다.이게 근데 단순히 클래스 분리만 해둬도 PR 에서 API 스펙이 어떻게 바뀌는지 쉽게 트래킹이 가능해지기 떄문에 이 부분 만큼은 번거롭더라도 실보다 득이 훨씬 많아서 꼭 분리해야한다고 생각해왔습니다.이 부분에 대해서 어떻게 생각하시는지 궁금합니다.

안녕하세요 토비님! 강의를 보다가 궁금한 점이 생겨서 질문 드립니다. 테스트 코드 작성시 EmailSender같은 경우나 , 외부 요인(?) 같은 경우에 저는 테스트 코드가 외부요인에 의해 영향받기를 원하지 않아 @MockitoBean을 사용하는데요 그런데 강의에서는 왜 @MocktioBean을 사용하시지 않고 @TestConfiguration을 사용하셨는지 궁금합니다!감사합니다!

38강 10분 13초에서 자신의 정보를 업데이트 하는 로직 만드는 부분에서 궁금한 점이 생겼습니다.로그인된 사용자만 자기 정보를 업데이트 할 수 있는 기능을 웹 API 쪽의 어댑터에서 만든다고 하셨는데 왜 그런걸까요? 애플리케이션에서 검증을 하면 안되는걸까요?

어떻게 들어가야되죠?!

Member activate 호출 시 MemberDetail의 activate 또한 호출 하게 되는데요.이때 MemberDetail의 activate 로직에서 this.deactivatedAt = null 을 통해 비활성 일시는 초기화 해주어야활성 -> 비활성 -> 활성 -> 비활성 시 deactivatedAt이 null임으로 문제가 없을 것 같은데 어떻게 생각하시나요?

MemberRegisterTest를 진행할 때 @SpringBootTest를 사용해서 테스트를 진행했는데요서비스 테스트에는 @ExtendWith(MockitoExtension.class)를 사용하는 경우를 많이 봤습니다 헥사고날 아키텍처에서는 애플리케이션과 도메인이 중심이 되기 때문에 서비스에서 @SpringBootTest를 사용한걸까요?

안녕하세요.ApiControllerAdvice에서 하나의 Handler 메서드에서 아래 2개 Exeception 타입을 처리하시도록 변경하셨는데요.- DuplicateEmailException- DuplicateProfileException 이렇게 할 경우, 아래와 같이 두 Exception의 공통 타입인 RuntimeException 객체로 파라미터를 받아야 하는거 아닐까요?@ExceptionHandler({DuplicateEmailException.class, DuplicateProfileException.class}) public ProblemDetail duplicateExceptionHandler(RuntimeException e) { return getProblemDetail(HttpStatus.CONFLICT, e); } 감사합니다.

안녕하세요.Member와 MemberDetail의 연관관계 주인이 바뀐게 아닌가 싶습니다.비록 1:1 관계이고, 두 객체 인스턴스가 동시에 생성되고 테이블에 영속화 되게끔 설정된 거는 맞지만,논리적으로 Member 엔터티가 상위 엔터티이고, MemberDetail이 하위 엔터티가 맞는 것 같아요.추후 Member 엔터티를 참조하는 다른 엔터티가 만들어질텐데,MemberDetail을 참조하는게 아니라 Member를 참조해야 하고요.관련한 의견 부탁 드립니다.감사합니다.

안녕하세요.도메인 영역에 @Entity, @Query 애너테이션을 사용하는게 문제가 없다는 내용과 이유를 강의에서도, 질문&답변에서도 잘 설명해 주셨고, 모두 확인했습니다. 동일한 이유로,강의에서 DuplicateEmailException에 @ResponseStatus 애너테이션 사용 시, 의존성 문제에 대해서 언급한 부분도, JPA 애너테이션을 사용할 수 있다는 동일한 근거로 허용되어도 문제가 없는게 아닐까요?물론, @ResponseStatus 사용 시에 상태 코드 외에 추가적인 메시지 설정이 불가능하다는 등 단점이 있어서 사용하지는 않겠지만요. 그저 기술 의존성 침투 관점에서 궁금해서 문의 드립니다.감사합니다.

쉽게 이해할 수 있게 설명해주셔서 강의 잘 봤습니다. 👍 강의 후반부(39. 문서와 코드 다듬기)에 MemberRepository에 @Query를 사용하면서 JPA 종속성이 추가되었는데 이 부분에 대해서 언급 없이 2가지 조인 방식과 관련하여 설명하고 넘어갔습니다.강의 중반부(23. 회원 애플리케이션의 포트 정의)의 MemberRepository 설명과 같이 spring-data-commons의 Repository라는 마커 인터페이스를 사용하는 것은 동의하나 application layer에 기술 종속성이 추가된 내용 관련하여 부가 설명 요청 드려도 될까요? 물론 다음 강의에 해당 설명이 있을것으로 생각되지만.. MemberQueryRepository로 분리하고 adapter layer에서 구현하는 방향이 더 좋아보이는데 개선 방향도 같이 부탁드립니다.

해당 강의를 수강하고 하루죙일 찾아봤지만 실질적으로는 문제를 해결하지 못했습니다. ㅜㅜ 문제가 왜 발생했는지 추적한 결과실제로 xml를 불러들일때, fk 관련 속성을 잘 갖고 오지만,@JoinColumn 을 생성할 때 fk 속성을 삽입하는 코드가 실질적으로 존재하지 않고,fk제약 조건 생성을 위해 alter 시에@JoinColumns로 지정됩니다. 실제 어노테이션 기법으로 작성 할 경우 @JoinColumn으로 수집이 되지만,-참고-@JoinColumns 으로 수집 시xml 스펙에서 join-column 태그는 Unbounded로 스펙이 정해져 그렇게 처리 된 거 같아요. 하이버네이트 6.6 버전에서는 jpa 매핑 관련해서 xml 3.1 버전으로 관리되고, 7.0 버전부터는 xml 7버전으로 매핑이 관리될 것 같습니다. 하이버네이트 6.6 버전에선 실질적으로 버그라고 생각되고, 7.0 버전에는 JPAXMLOverridenAnnotationReader 클래스가 사라진 상황이라 7 버전으로 올려서 확인해봐야 할 것 같지만, 스프링 부트 3.x.x버전은 아무래도 하이버네이트 6.6 버전 기준으로 버저닝이 될 거 같아 해당 문제의 해결 방법은 실질적으로 찾진 못했습니다. ㅜ

찾아보다가 잘 못찾겠어서 문의 드립니다 ㅜㅜ

토비님의 의견에 동의합니다.화면에서 필드 하나 필요하다는 수정사항을 처리하기 위해 Presentation 레이어 이외의 클래스들을 수정하고 싶진 않아요. 그럼에도 불구하고 현업에선 정말 수많은 이유를 들어서 DTO로 반환하는 걸 유지하려고 합니다. 별도의 관심사를 끌어안게 되면서 애플리케이션 레이어의 테스트 코드 작성이 까다로워지고, 그로 인해 안정성이 하나씩 무너지고 균열이 생기기 시작하는 지점이 이곳이지 않을까 싶어요. 어찌보면 강의를 들을까 고민하던 때에 가장 매력있게 보였던 챕터였고, 무언가 해답을 얻을 수 있을까 했지만 여전히 뭔가 용기가 생기진 않는 것 같습니다.물론 그것이 토비님 탓은 아니죠. 훌륭한 가르침이지만, 단지 이것을 제 현장에 전파할 때 발생할 어려움에 벌써 머리가 아파지는 것.. 그 뿐입니다. 질문은 아니고 그저 넋두리였습니다.나머지 강의 마저 잘 들어보겠습니다. 감사합니다

맹목적인 파라미터의 숫자가 아닌 보통 함축적 정보를 전달하기 위해 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 계층이 바뀌더라도 핵심 비즈니스 로직은 변하지 않아야 한다 (계층형),는 점에서 둘의 지향점은 같다고 느낍니다. 혹시 제가 놓치고 있는 중요한 관점이 있을까요?토비님께서는 이 두 아키텍처를 어떻게 구분하시고, 어떤 기준을 중요하게 보시는지 궁금합니다.

안녕하세요 토비님,우선 강의를 통해 제가 알고 있던 헥사고날과 DDD(도메인 주도 설계)에 대해 다시 한번 깊이 생각해볼 수 있는 소중한 경험이 되었습니다. 좋은 강의 만들어주셔서 정말 감사합니다.토비님께서 생각하시는 헥사고날에, DDD 과 멀티 모듈의 바람직한 설계에 대해 궁금해서 질문을 남기게 되었습니다. 여기서의 멀티 모듈은 우선 MSA 를 제외하고 순수 멀티 모듈을 통해 시스템을 설계를 한다는 것을 전제하고 있습니다.가장 흔하게 보이는 멀티 모듈 구성의 패턴은 Storage (JPA), External (외부 Dependency), N 개의 서비스에 해당하는 Web Server 모듈 & 기타 등이 있는 것 같은데요. 멀티 모듈을 현 강의에서 보여주고 말씀해주시는 헥사고날과 DDD 와 결합했을 때, 어떻게 구성하면 좋을지 많은 생각이 들고 또한 현업에서 비슷한 고민을 하고 있어서 토비님의 생각이 궁금해 질문을 남기게 되었습니다.감사합니다.

도메인에 "속성과 행위가 모두 포함"되어야하는데 그러면 만약에 "행위" 자체가 "외부 의존"을 가져야만 하는 경우에는 이런 것은 어떻게 만드는 것이 좋을까요?