토비님 안녕하세요! 좋은 강의 만들어 주셔서 감사합니다. 객체지향 프로그래밍에서는 객체의 내부 구현이나 구조를 외부에서 직접 알 필요가 없도록 캡슐화하고, 객체의 행동을 통해 상호작용하는 것이 중요하다고 알고 있습니다. 기존 테스트에서는 Course 내부의 detail 객체에 직접 접근합니다. 이를 아래와 같이 수정해봤습니다. public class Course extends AbstractEntity { public LocalDateTime getPublishedAt() { return detail.getPublishedAt(); } } @Test void publish() { course.submitForReview(); course.publish(); assertThat(course.getStatus()).isEqualTo(CourseStatus.PUBLISHED); //assertThat(course.getDetail().getPublishedAt()).isNotNull(); assertThat(course.getPublishedAt()).isNotNull(); assertThatThrownBy(() -> course.publish()) .isInstanceOf(IllegalStateException.class); } 이러한 판단이 객체지향의 캡슐화, 정보 은닉 관점에서 올바른지 궁금합니다.
안녕하세요, FlushModeType.COMMIT 에 대한 부작용으로 기재하신 예시코드 관련 질문 드립니다. em.setFlushMode(FlushModeType.COMMIT); // 1. 회원 A 저장 em.persist(new Member("회원A")); // 2. 회원 조회 (JPQL) // 플러시가 안 일어남 -> DB에는 '회원A'가 없음 -> 조회 결과 0건 List<Member> list = em.createQuery("select m from Member m where m.name = '회원A'", Member.class) .getResultList(); // 결과: 방금 저장했는데 조회가 안 되는 미스터리 발생 😱 만약 Member 엔티티 클래스의 ID 생성 전략이 IDENTITY인 경우 em.persist(new Member("회원A")); 에 의해 INSERT 쿼리가 실행되므로, 그 아래 코드에서는 해당 데이터가 조회되지 않나요? 데이터 불일치 문제가 발생할 수 있으니 COMMIT 모드는 확실한 이해 하에 사용하라는 것은 확실히 이해했습니다! 다만 예시코드 보다가 급 궁금해져서요ㅎㅎ
안녕하세요. 토비님 DIP와 관련하여 질문이 있습니다. "course" 컴포넌트 <- "curriculum" 컴포넌트는 단방향 의존성을 가져야하기 때문에, CurriculumValidator.class를 DIP를 통해 course 패키지로 옮긴 것을 이해하였습니다. 하지만, CurriculumValidator에서 던지는 예외인 InvalidCurriculumException.class는 "curriculum" 도메인에 속해 있습니다. 이것은 결국 양방향 의존성을 가지게 되는 것 아닌가요? 만약, 양방향 의존성이 맞다면, CurriculumValidator 인터페이스는 ValidationException을 던지도록 선언하고, CurriculumValidator인터페이스 구현체인 "CurriculumModifyService.class"는 "InvalidCurriculumException" 을 catch해서 ValidationException을 던지도록 수정하는 방법도 괜찮을까요?
안녕하세요 토비님! 오랜만에 강의를 복습하다가 궁금한 점이 생겨 질문드립니다. 제가 헥사고날 아키텍처를 외부 서비스나 인프라 연동이 많은 시스템에서 주로 사용하는 구조 라고 이해하고 있었는데요. 강의에서는 비교적 작은 시스템에도 헥사고날 아키텍처를 적용하셔서, 제가 잘못 이해하고 있었던 건지 궁금합니다. 현재 작은 규모의 신규 프로젝트를 준비하고 있고, 도메인 모델 패턴과 풍부한 도메인 모델을 적용해보려고 합니다. 다만 외부 서비스 연동은 거의 없을 예정이라, 이런 경우에도 헥사고날 아키텍처를 적용하는 것이 적절한지, 아니면 오버엔지니어링이 될 수 있는지 판단이 잘 서지 않습니다. AI에게 물어봤을 때는 헥사고날 아키텍처 도입을 고려할 수 있는 기준으로 외부 연동의 수뿐만 아니라, 하나의 Port에 대해 구현체가 둘 이상 존재하거나 향후 교체 가능성이 있는지 도 이야기하더라고요. 강의에서 DDD와 헥사고날 아키텍처가 잘 맞는다고 설명해주셨는데, 결국 헥사고날 아키텍처를 선택할 때 외부 서비스 연동이 많은지 Port의 구현체가 여러 개이거나 교체 가능성이 있는지 도메인을 기술적인 의존성으로부터 분리할 필요가 큰지 같은 요소 중 무엇을 주요 기준으로 봐야 할까요? 작은 시스템이고 외부 연동도 거의 없다면 레이어드 아키텍처로 시작하는 것이 나은지, 아니면 풍부한 도메인 모델과 DDD를 적용한다는 이유만으로도 헥사고날 아키텍처를 선택할 충분한 이유가 있는지 궁금합니다.
평소에 인터페이스와 구현체를 만들때 테스트를 어디에 만드는게 맞을까란 고민을 했었는데, 마침 토비님이 강의에서 언급해주셔서 너무 반가웠는데요. 테스트는 인터페이스에 만들라는 말씀 잘 이해했습니다. 스펙을 테스트하기에 인터페이스를 대상으로 테스트를 만들어야하는것도 이해를 했는데요. 구현체가 2개 이상이 되면 어떻게 하시는지 궁금합니다. 각 구현체들이 스펙을 준수하는지 테스트 코드를 작성해야할텐데 인터페이스를 대상으로 테스트를 작성하면 구현체가 1개일땐 문제가 없는데 2개 이상일땐 좀 난감해지더라고요.
‘자바 ORM 표준 JPA 프로그래밍 - 기본편’ 강의가 올해 안으로 리뉴얼될 예정이라고 들었는데, 혹시 대략적인 리뉴얼 시기를 알 수 있을까요? 현재 강의를 바로 수강할지, 우선 프로젝트를 진행하면서 기다렸다가 리뉴얼된 강의를 수강할지 고민 중이라 문의드립니다. 감사합니다.
안녕하세요. 강의 잘 듣고있습니다. 오늘 수강한 "엔티티 식별자와 JPA 엔티티" 에서 JPA 엔티티로 만들었다고해서 달라진게 없다 라고 표현하셨는데요. 애노테이션을 붙여서 컴파일 단계의 의존성은 생겼지만 해당 클래스가 다른 기술적 종속이 생긴건 아니라고 말씀하신거에 질문이 있습니다. 일단 애노테이션을 붙인 것을 용인할 수 있다는건 이해했고, 저도 동의합니다. 그런데 JPA 엔티티가 됨으로써 해당 클래스는 final 로 만들 수 없고, 생성자도 기술적 요구사항에 의해 최소 protected 로 공개할 수 밖에 없는데요. 이번 강의에서도 기존 의도는 private 이었지만 기술을 도입함으로써 애노테이션을 붙이는 것 이상의 작업이 있었습니다(생성자의 접근 수준 변경). 정말 애노테이션만 붙이고 아무것도 하지 않았다면 납득할 수 있지만 애노테이션 외에 다른 변경이 발생했는데도 기술적 종속이 없다고 볼 수 있을까요? 이정도 수준의 변경과 의존은 트레이드오프로 용인할 수 있다고 생각하면 할수는 있지만 엄밀히 따진다면 객체 설계에 영향을 줬다고 생각하는데, 어떻게 생각하시는지 궁금합니다.
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (모름) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. 궁금증이 생겨서 질문을 드립니다. 현재 시점(26.8) 에서 강의를 듣고 있는데요. pdf 을 보면, 시간 지남에 따라 assertEquals() 내용이 달라 지듯이, 그 동안 강의 에서 배운 assertj 의 assertThat().isEqualTo()나, 다른 방법 들이 있어서 어떤 것을 쓰는게 맞는지 몰라서 여쭈어 봅니다. 첫 번째는 assertEquals(), assertThat()이고 두번째는 assertThrows() , assertThatThrownBy() 입니다. 영한님 이라면 어떤 것들을 쓰실지 궁금합니다. 답변 부탁 드립니다.
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (모름) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. 궁금증이 생겨서 질문을 드립니다. 스프링 트랜잭션 전파7 까지 지 강의를 보면서, 전 섹션 스프링 트랜잭션 의 이해 에서, 트랜잭션 aop 주의 상황 프록시 내부 호출1 -2 에서 만든, InternalCallV1Test ~ v2Test 가 개념적으로 비슷 하다 라는 느낌을 받았습니다. 이유가 객체가 자기 자신을 참조하고 있어서 내부 적용에 트랜잭션 작동이 안되서 , 새로이 만들어서 적용하는 모습 을 보고?, 말입니다. 영한님이 예제를 잘 만들어서 그런 건지는 몰라도 InternalCallV1test 가 현재 하고 잇는 BasicTxTest 랑 비슷하다고 생각도 듭니다. 이렇게 생각해도 되는지 알고 십습니다. 답변 부탁드립니다.
헥사고날 아키텍처와 DDD를 적용할 때, 화면에 강하게 연관된 조회 데이터를 어떻게 다루는 게 좋은지 궁금합니다. 예를 들어 채팅방 목록 화면에서 각 채팅방마다 다음 정보를 한 번에 보여줘야 한다고 가정하겠습니다 . ex) 채팅방 이름, 마지막 채팅 내용, 읽지 않은 채팅 개수 이 정보를 구하려면 room, chat, read_status 같은 여러 테이블을 함께 조회해야 하고 , N+1 문제를 피하려면 Querydsl 이나 JDBC 등을 사용해서 한 번의 쿼리로 조회하는 방식이 필요해 보입니다 . 이 경우 제 생각에는 기존 포트와 분리해서 , 조회 전용 port 와 query repository interface 를 application 계층에 두고 , adapter 계층에서 Querydsl/JDBC/MyBatis 등으로 구현하는 것이 해결책 같습니다. 이런 식으로 cqrs패턴을 적용하는 것이 유일한 해결책인가요? 혹시 더 나은 방법이 있는지 궁금하여 질문남깁니다. (강의 너무 잘 보고 있습니다)
[Lv1] 면접에서 설명할 수 있는 Spring Boot - 경험으로 답변하는 백엔드 개발
implementation 'com.h2database:h2' 이걸로 h2 database를 추가했는데 로그에 h2 database가 추가되지 않아 확인해보니 implementation 'org.springframework.boot:spring-boot-h2console' 이 부분을 추가해야한다고 합니다. Spring Boot 4.x부터 H2 콘솔 자동설정(H2ConsoleAutoConfiguration)이 spring-boot-autoconfigure에서 분리되어 별도 모듈 spring-boot-h2console로 이동했습니다. 이 내용에 대해서 확인해주시면 감사할거 같습니다! 좋은 강의 제공해주셔서 감사합니다!
안녕하세요. Member 객체를 생성할 때, 다른 방법을 선택해 보는 것은 어떨까요? 기존에는(설계 트레이드 오프 개선 전) Member.register() 가 MemberRegisterRequest 에 직접 의존하고 있었는데, 도메인 모델이 요청 DTO를 알지 않도록 의존성을 반대로 두는 방법입니다. MemberRegisterRequest 에서 Member 객체를 직접 생성하는거죠. public record MemberRegisterRequest( ... ) { public Member toMember(PasswordEncoder passwordEncoder) { return Member.register(email, nickname, password, passwordEncoder); } } public class Member extends AbstractEntity { ... public static Member register(String email, String nickname, String password, PasswordEncoder passwordEncoder) { Member member = new Member(); member.email = new Email(email); member.nickname = requireNonNull(nickname); member.passwordHash = requireNonNull(passwordEncoder.encode(password)); member.status = MemberStatus.PENDING; member.detail = MemberDetail.create(); return member; } ... } public class MemberModifyService implements MemberRegister { ... @Override public Member register(MemberRegisterRequest registerRequest) { checkDuplicateEmail(registerRequest); Member member = registerRequest.toMember(passwordEncoder); memberRepository.save(member); sendWelcomeEmail(member); return member; } ... } MemberRegisterRequest.toMember(passwordEncoder) 에서 Member.register(email, nickname, password, passwordEncoder) 를 호출하면 Request DTO → Domain 방향으로만 의존합니다. 별도의 MemberRequestInfo 같은 파라미터 객체도 필요하지 않아 구현이 단순합니다. Request DTO를 단순 데이터 전달 객체로 유지하려면 서비스 계층에서 각 값을 꺼내 Member.register() 에 전달하는 방법도 가능합니다. (이 방법보다는 이전 방법이 서비스 계층을 간결하게 유지하는 방법이긴 합니다.) 이런 방법을 기본 개발 규칙으로 두면, 의존성 방향도 문제 없고, 추가적인 객체(예: MemberRequestInfo )를 생성할 필요도 없어서 충분한 이점이 있습니다. 다만, register() 에 전달해야 할 파라미터가 많아진다면 번거롭긴 하겠네요. 이 방법에 대한 의견도 부탁 드립니다. 감사합니다.
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. 궁금증이 생겨서 질문을 드립니다. 이 강의에서 Quersydsl 설정 하는 것을 보았는데요. 여기에서 질문입니다. 저가 스프링에서 gradle를 기본 설정 할때 run은 인텔리제이로 test는 그레이들로 설정하는데요 사진 처럼요 이렇게 설정 하려면 영상에 나온 두 가지 방법 (인테리제이 일때는 리빌드 프로젝트, 그레이들 때는 아웃터에서 컴파일자바,) 을 다써야 하나요? 테스트 및 런 실행 환경이 달라서 궁금증이 생겼습니다. 그리고 이렇게 설정한 이유는.. 예전에 그레이들로 설정햇을때 무언가 달라서 이렇게 설정 했던 걸로 기억 하는데 정확히 기억 안나네요. 답변 부탁 드립니다.
JPQL에서 DTO를 조회할 때 new 패키지명.DTO명(...) 을 생략하고 바로 select m.id, m.name, t.name 이렇게 작성해도 DTO로 반환이 되는데 원래 가능한 내용인가요?? @Query("select new study.datajpa.dto.MemberDto(m.id, m.name, t.name) from Member m join m.team t") List<MemberDto> findMemberDto(); @Query("select m.id, m.name, t.name from Member m join m.team t") List<MemberDto> findMemberDtoNot();
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. [질문 내용] 강의보고 책으로 복습하다가 궁금한 점이 있어서 질문드립니다. jpa 책 105쪽에 변경감지에 관한 내용입니다. 엔티티가 영속성 컨텍스트에 보관될 때 최초의 상태(persist())를 스냅샷으로 저장해두고 플러시 시점의 엔티티를 비교해서 변경사항에 대한 수정 쿼리를 쓰기지연 sql 저장소에 보낸다고 되어있습니다. 이 메커니즘은 이해가 되는데 persist(); setName(); flush(); 여기서 persist()를 하게 되면 실제 db에 바로 반영이 되는 것이 아니라 영속 컨텍스트에 저장(1차캐시), 이후 insert 쿼리를 쓰기 지연 저장소에 저장하게 됩니다. 이후 엔티티의 이름을 변경하고 플러시할 경우 스냅샷과 플러시 시점의 엔티티 상태를 비교해서 변경 부분에 관한 수정 쿼리를 쓰기지연저장소에 보낼 때 쓰기지연저장소에는 insert와 update 두 쿼리가 있고 플러시할 때 insert, update 두가지 모두 실행되는 걸까요? 아니라면 이유가 궁금합니다! 찾아보니까 insert만 나간다고 하는데 왜 그런지 도무지 이해가 안됩니다.
