UUID, Random 등 자주 사용하는 의존성의 경우, 강의에서 설명해주신 방식으로 공통으로 사용하는 유틸성 Holder 인터페이스를 만들어놓고 프로젝트에서 함께 사용하는 방식으로 개발하나요? 자주 사용되는 클래스들이다 보니 여러 곳에서 필요할 것 같은데(한 곳에서 Holder 인터페이스를 만들어두면 될 것 같은데) 실제로는 어떻게 사용하시는지 궁금해서 여쭙습니다.

안녕하세요 강의 잘듣고 있는 수강생입니다.헥사고날 아키텍처를 이번 토이프로젝트에 적용하면서강의에서 알려주신대로 설계를 이렇게 유연하게 변경하면n+1문제도 해결 할 수 있다고하셨는데예를들면MemberRepository impl에서 멤버 아답터만 주입받고있는상황에서 팀 엔티티랑 연관관계가있는 상황에서N+1 문제를 해결하려면MemberRepository impl 에서 memberRepository말고TeamRepository도 주입받아서 한번에 다 불러와서 도메인 엔티티에 저장해야하나요? 아니면 서비스 계층에서 각각 레파지토리에서 불러온다음MemberRepository에서 넘겨준다음 도메인 모델을 리턴할때 넣어줘야 하나요 n+1문제를 서비스계층에서 결합할지 레포지토리 계층에서 결합할지 궁금해서 질문드립니다. 

안녕하세요 ! 도메인과 영속성 객체 구분하기 수업에서 1분 34초에서 UserEntity 에 있는 행을 복사하는데 이 때 나오는 단축키가 궁금합니다.  

Domain -> Response 변환 코드를 Domain에 정의해두고Controller에서 Domain 메서드를 호출해서 Response를 변환하는게 맞나는 건 이해했습니다. 근데 실제 API에 해당 내용을 적용하려고 보니 Domain 단 건 조회보다는 List<Domain>을 반환하는 경우가 훨씬 많았습니다. 따라서 List<Domain>을 List<Response>로 변환해야 하는데 해당 작업을 for문이나 Stream으로 Controller로 처리하려니 Controller 코드도 지저분해지고 Controller가 하는 역할에 부합하지 않게 되는 것 같습니다.List<>를 변환할 때는 어디서 하는게 올바른 것인지 질문드립니다! 

Interface를 이용하여 완충재를 두고 테스트를 할 때는 테스트를 위한 mock 구현체를 이용하여 final 메소드를 stub하는 것을 피한다는 것은 이해를 했는데요. 갑자기 드는 생각이 결국 프로젝트가 배포될 때는 SystemUuidHolder라는 구현체를 사용하게 되고 그러면 해당 클래스의 대한 테스트도 진행해야 하나요? 진행한다면 해당 클래스는 UUID를 사용하고 있으니 final 메소드를 stub하는 상황을 피할 수 없게 되는건가요?

서비스 테스트 시 Repository 상속해서 FakeRepository를 생성자 주입을 통해 진행한다는 내용에 대해서는 이해하고 실습해 보았습니다.그런데 만약 Repository 메서드 중 JPA의 on 절을 이용한 join을 사용해 데이터를 가져오는 경우 FakeRepository의 내부 구현이 궁금합니다내부에 Id와 List를 통해 해당 엔티티에 대한 정보를 저장할 수 있지만, Join을 하는 경우 외부 테이블의 정보가 필요하기 때문에 이를 Fake하고 싶을 때는 어떻게 해결할 수 있는지 알려주시면 감사하겠습니다.

service 레이어는 repository 보다 상위 레이어에 있습니다.일반적으로 service 레이어는 repository 를 주입받아서 사용됩니다.OOP 원칙에서도 상위레이어는 하위레이어를 알아도 괜찮은것으로 알고있습니다. 반대로 하위레이어는 상위레이어를 알아서는 안됩니다.'외부 연동을 다루는 방법' 강의 1:53 ~ 2:04 에상위 레이어인 Service 가 infraStructure 에 의존하는 모습을 보이기때문에 라고 하셨습니다. 이말을 해석하면, 앞으로 변경될 코드에서는 UserService 는 interface 인 UserRepository 를 의존하게됩니다. 그러나 자세히 들어가면 service 레이어가 UserRepository 에 의존하는것이 아닌 의존성역전을 통해 그의 Impl 을 받게됨으로 약결합이 되게됩니다. 그러므로, service 가 interface 인 UserRepository 에 의존하는건 아니기때문에 service 패키지로 해당 interface 를 옮긴것인지 궁금합니다.

안녕하세요. 우선 강의 너무 잘 들었습니다.설계를 개선하며 소형테스트를 풍부하게 작성할 수 있다는 것을 보고 이를 체화하려고 공부중인데요,강의에서 배운것을 적용하다가 막힌 곳이 있어서 질문드립니다.우선, 저는 강의와 유사하게 Repository를 추상화해서 프로덕션(~RepositoryImpl)과 테스트 환경(Fake~Repository)을 다르게 가져가고 있고, 막힌 부분은 아래와 같습니다.프로덕션에서 groupBy를 사용하고, Dto로 바로 조회하는 방식으로 프로덕션 Repository에 코드를 작성한 부분이 있는데,이를 Fake Repository에서 작성하려니까 막막하더라구요왜 FakeRepository에 작성하려 하냐면, 제가 이해하기로는 FakeRepository를 구현해야 Service 레이어를 테스트할 때, 소형테스트로 작성할 수 있다고 이해를 했기 때문입니다. 막힌 부분에서 여러 고민해보다가, 다양한 조건절과 그룹핑이 들어간 쿼리는 어떻게 Fake Repository에 작성해서 테스트할 수 있을까? 하는 궁금증이 생겼습니다. 그래서 질문입니다.Fake Repository를 사용해서 일부 Service 레이어의 로직을 테스트할 수 있지만, 좀 더 복잡한 쿼리들은 Fake로 구현(stream, filter등을 사용해서)하기 어려우니, Fake로 구현하지 않고 중형 테스트로 테스트한다.그리고 위의 기준이 소형테스트로 테스트할 지, 중형테스트로 테스트할 지 고려할 기준이 된다..?저는 위와같이 생각이 이어지는데, 혹시 옳은 생각일까요? 아님 열심히 Fake로 구현을 해봐야하는 것일까요?그것도 아니라면 다른 방법이 있을까요? 강사님은 복잡한 쿼리들을 어떻게 하시는지 궁금합니다..!열심히 강의해주셨는데, 막상 적용해보려니 쉽지 않아서 민망합니다..답변 미제공 강의지만, 호옥시나 하는 마음에 질문 남깁니다.🥹좋은 강의 감사드립니다 

중형 테스트는 멀티 스레드, 멀티 프로세스를 허용하는 테스트라고 이해했는데 그 설명을 하시면서 "멀티 프로세스와 멀티 스레드를 사용할 수 있는 완화조건이 생기죠. 이는 다시 말해 h2 같은 테스트용 DB를 사용할 수 있게 된다는 의미입니다." 라고 하셔서요! 혹시 h2를 사용하려면 멀티 스레드나 멀티 프로세스 환경에 있어야 한다고 이해해도 되는걸까요? "h2는 멀티 스레드, 멀티 프로세스 환경에 있어야 하기 때문에 h2를 사용하는 순간 중형 테스트로 보면 된다"로 이해하면 될까요??

섹션 21부 실기 수업 - 어쨌든 테스트 코드에서 사용하는 기존 프로젝트 위치가 혹시 어디 있나요?

UUID에 대해 제가 작성한 로직의 방향이 맞는지 확인해 보고싶은데, 문제관련 코드는 어디에 있나요 ?

안녕하세요! 강의 너무 잘듣고있습니다.소스코드 내에서 UuidHolder와 User의 관련 의존성 방향에 대해 질문이 있어 글 남깁니다public static User from(UserCreate userCreate, UuidHolder uuidHolder) { return User.builder() .email(userCreate.getEmail()) .nickname(userCreate.getNickname()) .address(userCreate.getAddress()) .status(UserStatus.PENDING) .certificationCode(uuidHolder.random()) .build(); }위 코드에서 Parameter값을 통해 User 객체가 UuidHolder 라는 클래스에 의존하게 되는데요. UuidHolder 의 경우 common 패키지의 application layer에 존재하는 것으로 알고 있습니다. Domain layer의 User객체가 application layer의 객체에 의존하는 것이 parameter형태로는 허용이 되는지 질문드립니다.

안녕하세요, 강의 잘보고 필요할떄마다 계속 보고 있습니다.현재 강의에선 도메인 객체와 영속성 객체(Entity class)를 분리해서 사용하여서 문제가 없을 것 같은데,보통 Entity class 에서 ID를 자동으로 생성하는 경우가 대부분이어서, 생성자를 생성 할 때, ID를 포함하지 않는 생성자를 많이 만드는 것으로 알고 있습니다.이 때, 테스트코드는 어떻게 작성해야할까요?소형 테스트를 작성한다면 H2 같읕 데이터베이스에서 객체를 가져오지 않는 한 아이디가 존재하지 않을텐데아이디로 비교하지 말고 다른 값들만 비교해야할까요?그렇다면 로직내에 findById() 같은 메서드로 객체를 불러와서 처리하는 경우가 있다면 어떻게 하시는지 궁금합니다. 객체의 아이디가 없으므로 로직내에서 아이디를 가져오거나 비교하는 경우가 있다면, NPE가 발생하여 테스트가 제대로 진행이 되지 않는 경우가 많을 것 같습니다.다들 보통 어떻게 하시는지 궁금하여 질문 남깁니다감사합니다

안녕하세요. 강의에 매우 깊은 감명을 받고 토이 프로젝트에 말씀해주신 부분들 적용해보고 있습니다.강의에서 가이드 주신대로 유효성 검증에 대한 테스트도 mock 라이브러리 없이 순수 자바 코드로 해보고 있습니다.기존 코드에서는 입력값 유효성 검증을 위해 @Valid 어노테이션을 사용했는데요. 스프링부트를 실행시키지 않으니 @Valid 어노테이션이 정상작동을 안해서 테스트를 작성하는데 어려움을 겪고 있습니다....ㅎㅎ그래서 유효성 검증을 하는 코드를 직접 작성해야 하나 고민하다가 질문을 남기게 되었습니다. 강사님께서는 유효성 검증에 대한 테스트 코드를 작성하는데 어떤 방법을 사용하시는지 궁금합니다.(@Valid는 자바 표준 스펙으로 알고 있어서 스프링을 실행시키지 않아도 방법을 잘 찾아보면 가능할 것 같다 라고도 생각하고 있습니다.)  

안녕하세요 강의 잘 보고 있습니다.다름이 아니라 이렇게 H2등을 쓰지않고 테스트 할 경우, 많은 테스트 데이터들을 셋업하는 것이 힘들것 같은데 보통 어떻게 처리하시나요?h2등을 사용한다고 하면 강의에서 알려주신 것 처럼 보통 .sql을 실행시켜서 사용할텐데,이렇게 소형테스트들에 테스트데이터를 java code로 반복문 돌면서 생성하자니 좀 번거러운 것 같은데 혹시 다른 방법이 있을런지 혹은 어떻게 하시는지 궁금하여 여쭤봅니다.환절기가 다가오는데 더위 조심, 감기 조심 하시길 바랍니다.감사합니다.

강의를 굉장히 감명 깊게 보고 Spring 기반으로 되어 있는 레거시 프로젝트에 도메인을 분리하고 유닛 테스트를 넣는 작업을 하고 있습니다. 여기에서 가장 답답한 게 단순한 유닛 테스트임에도 빌드 타임을 그대로 기다려야 한다는 점인데요. 비록 빌드 캐시 덕에 아주 오래 걸리는 건 아니긴 해도 몇십 ms면 끝날 테스트를 몇 초씩 기다려야 하는 점이 많이 답답합니다. 시간 상으로는 인메모리 db를 띄우는 것과 별 차이 없는 것 아닌가? 하는 생각이 들 정도예요. (물론 테스트 코드를 작성하기 쉬운 구조가 좋은 코드 구조라는 명제에는 이견이 없기 때문에 별 차이가 없다 하더라도 계속 진행할 예정입니다.)선생님께서도 담당하시던 시스템에 유닛 테스트를 붙이는 작업을 하셨다고 들었는데 이러한 부분은 어떻게 극복하셨는지 궁금합니다.

혹시 다음 강의는 어떤 내용으로 준비중이신지 궁금합니다

안녕하세요. 강의가 너무 재미있어 시간가는 줄 모르고 1편, 2편 강의 완강 하고있습니다. 2편, 테스트 관련해서 실습을 하던 중 고민이 생겨서 질문을 올리게 되었습니다.자바/스프링으로 코딩을 하다가 A Service와 B Service가 의존관계를 갖게 된다면 어떻게 해야할지가 너무 고민이여서요.만약 2편에 있던 도메인 User, Post에 User의 프로필 이미지 업로드기능, Post의 이미지 업로드기능이 있다고 할 때, File의 정보를 저장할 수 있는 File 도메인이 있어야 한다고 생각합니다.File에 대응하는 FileService를 만든다고 가정 하였을 때 DB 등에 파일의 정보 데이터를 저장하는 FileRepository, 파일을 업로드 하는 FileUploader를 만든 후 의존관계가 이런형태로 구성 되어야 한다고 생각합니다. FileService에 saveAndUpload() 라는 메서드가 있고 이 메서드를 공통으로 사용하고 싶을 때 UserServiceFacade, PostServiceFacade와 같은 형태로 퍼사드를 써야할지, UserService, PostService 에 각각 업로드 메서드를 구현을 해야할지 고민이 됩니다. Facade와 같은 형태로 코드를 작성하게 된다면 User, Post가 아닌 파일이 필요로 하는 도메인이 추가 될 때 마다 Facade를 작성해줘야하는 번거로움이 있을 것 같고,Service 각각에 업로드 메서드를 구현하자니 반복적인 코드가 들어가는 것이 마음에 조금 걸려서 질문드립니다.

답변해줘요.....................

서비스에서 사용하는 모델인 거 같은데제 생각입니다.다른 의견 적어주시면 감사합니다.