MemberDetail 테이블의 UK_MEMBER_DETAIL_PROFILE_ADDRESS 유니크 제약 조건과 관련해서 질문이 있습니다.39장 강의 마지막 부분에서, 해당 프로파일 주소(profile_address)를 빈 문자열로 바꿔 삭제할 수 있는 부분 테스트를 추가 하셨는데, 그런데 이렇게 되면 여러 사용자가 프로필 주소를 빈값으로 변경 할 경우 제약 조건에 충돌이 발생할 수 있을 것 같습니다.profile_address 값을 빈값으로 설정할 수 없도록 테스트를 조정하는게 더 맞아 보이는데 제가 생각한게 맞을까요?

같은 도메인이라도 depth에 따라 일반에서 코어로 바뀔 수 있는거 아닌가요?그리고 이게 서비스 운영하면서 바뀔 수 있지 않나요?

안녕하세요msa에서 db를 각자 쓰게되는 패턴이라면 join이 깨지지 않나 하는 생각이 들었습니다.혹시 join을 하다가 db가 나뉘게되어 쿼리 효율이 떨어지는 경우도 있을까요? 아니면 애초에 join이 안쓰이기 때문에 마이크로서비스로 분리가될까요 예를들어 사용통계같은걸 볼 땐 모노리스에서 msa 전환 전에 join이 들어갈 수 있을 것 같은데, db가 나뉘어버리면 join을 못쓰는거죠? 그럼 msa 전환해야한다면 그때가 데이터레이크를 만들 타이밍인걸까요?

안녕하세요 토비님!!강의를 완강하고 제 프로젝트를 리팩토링하면서 피드백받고싶은점이 생겨 질문글을 올립니다.Repository Port를 기술에 종속시키지 않기 위해 Adapter에서 JPA, MyBatis, QueryDSL을 조합하는 구조를 선택했는데, 이 설계 방향이 적절한지 조언을 구하고 싶습니다.현재 구조 core/ └── domain/ └── application/ └── required/ ← Port 인터페이스 └── ~Repository adapter/ └── persistence/ ├── ~RepositoryAdapter ← Port 구현체 ├── ~JpaRepository ← Spring Data JPA └── ~MybatisMapper ← Mybatis 매퍼 인터페이스 의존 관계 [Service] → [Repository] ←impl― [RepositoryAdapter] → [JpaRepository] → [MybatisMapper] → [JPAQueryFactory] (core) (core) (adapter) (adapter) 예시@Repository @RequiredArgsConstructor public class ItemRepositoryAdapter implements ItemRepository { private final ItemJpaRepository itemJpaRepository; private final ItemMybatisMapper itemMybatisMapper; @Override public List<Item> findBySearchRequest(ItemSearchRequest request) { return itemMybatisMapper.findBySearchRequest(request) .stream() .map(Item::from) .toList(); } @Override public List<Item> saveAll(List<Item> items) { return itemJpaRepository.saveAll(items); } } @Repository @RequiredArgsConstructor public class AuctionRepositoryAdapter implements AuctionRepository { private final JPAQueryFactory jpaQueryFactory; private final AuctionJpaRepository auctionJpaRepository; @Override public void deleteAllByRegionAndRealmId(RegionType region, Long realmId) { QAuction qAuction = QAuction.auction; BooleanBuilder filter = new BooleanBuilder(); filter.and(qAuction.region.eq(region)); if (realmId == null) { filter.and(qAuction.realmId.isNull()); } else { filter.and(qAuction.realmId.eq(realmId)); } jpaQueryFactory.delete(qAuction) .where(filter) .execute(); } @Override public int saveAll(List<Auction> auctions) { if (auctions.isEmpty()) return 0; return auctionJpaRepository.saveAll(auctions).size(); } } 이 구조를 선택한 이유동적 쿼리, 벌크 연산 등 JPA만으로 해결하기 어려운 케이스가 있어 MyBatis와 QueryDSL을 병행 사용하고 있습니다.일반적인 방식인 Port 인터페이스가 Spring Data JPA Repository를 상속하는 구조를 채택하지 않은 이유:MyBatis나 QueryDSL 기반 구현체를 만들 수 없음CustomRepository 인터페이스를 별도로 만들어야 하는 복잡도 증가현재 방식의 장점:Port 인터페이스가 순수 Java 인터페이스로 유지됨RepositoryAdapter에서 상황에 맞는 기술을 자유롭게 조합 가능추가 인터페이스 없이 단순한 구조 유지저는 현재 구조가 의존 관계도 외부에서 내부로 향하고 테스트도 쉬워서 괜찮다고 생각하는데 토비님의 생각도 듣고싶습니다!! 좋은 강의 감사합니다!!

spring-boot 버전 4.0.0 으로 프로젝트를 생성하면 어플리케이션 구동 시 아래와 같은 오류가 발생합니다. (현재 2025-12-08)3.x 버전으로 내리면 발생하지 않으니 참고해주세요.2025-12-08T18:40:05.881+09:00 INFO 2496 --- [splearn] [ main] .s.b.d.c.l.DockerComposeLifecycleManager : Using Docker Compose file /Users/coffeenjava/work/study/splearn/compose.yaml2025-12-08T18:40:06.285+09:00 ERROR 2496 --- [splearn] [ main] o.s.boot.SpringApplication : Application run failedtools.jackson.core.exc.StreamReadException: Unexpected character ('\' (code 92)): expected a valid value (JSON String, Number, Array, Object or token 'null', 'true' or 'false')at [Source: REDACTED StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION disabled); byte offset: #UNKNOWN]at tools.jackson.core.JsonParser._constructReadException(JsonParser.java:1800) ~[jackson-core-3.0.2.jar:3.0.2]

안녕하세요 토비님 강의 잘 수강하고 있습니다. 좋은 강의 감사드립니다. 저는 JPA엔티티를 도메인 모델로 사용하고 애플리케이션에서 이를 리턴하고 있습니다.그런데 새로운 팀원 한명이 이렇게 이야기하더군요이전에 마이바티스를 사용하다가 JPA가 나온거처럼 이를 대체하려면 코드변화가 필요할 것 입니다 사실 이것도 저는 맞는 말이라고 생각합니다. JPA 엔티티를 참조하는 모든 부분을 수정이 필요할 것 같습니다. 그럼에도 불구하고, 트레이드오프 관점에서 보면 현재 잘 사용하는 JPA엔티티를 그대로 사용하는게 더 효과적이라고 생각합니다. 여기서 궁금한게, 이렇게 새로운 데이터접근 기술이 나오게 되는 것까지 고려하는게 맞을까요? 어떠한 논리를 펼쳐서 JPA를 그대로 의존하는게 좋다고 이야기하는게 더 설득력이 있을까요?

안녕하세요 .  강의에서 애그리거트 루트가 하위 도메인을 일관성을 유지하기 위해member.updateInfo() 로 MemberDetail updateinfo() 를 호출하는것을 보았는데요 만약 Profille에 여러 속성(프로필주소, 프로필이미지를 불러올 수 있는 주소,정보 등이 존재)이 있어 값 타입이 아닌 Entity로 존재해야 할 경우엔 member.updateInfo() -> memberDetail.updateInfo() -> profile.updateInfo() 로 depth가 내려갈 것 같은데요. 뭔가 잘못된 방법 같아서요..혹시 이런 경우에는 어떻게 도메인을 설계해야 좋을지 궁금합니다...!!

Pageable 인터페이스와 @PageableDefault 를 컨트롤러부터 사용하면 편하게 작업할 수 있을 것이라고 생각하고 있습니다.그런데 spring-data에서 제공하는 것들이라 컨트롤러나 애플리케이션(서비스)에서 사용하면 안 될 것 같아서 새롭게 객체를 정의해서 사용해야 하는 것인가라는 생각이 드는데요. 한편으로는 유틸느낌으로 사용해도 되지 않을까라는 생각이 들기도 합니다. 실제로 @PageableDefault 이것은 org.springframework.data.web 패키지에 들어있어서 web계층을 대상으로 만들어진 것 같구요어떤식으로 풀어나가야 할까요? 추가적으로 Http interface를 사용하기 위해 @HttpExchange을 사용할 경우 required패키지 인터페이스에 바로 붙여서 사용해도 무방한걸까요?

안녕하세요 토비님! 애그리거트를 사용할 때 질문 사항이 있습니다.예) A도메인 B도메인이 있다 A는 애그리거트 루트이고 B는 A의 부속 엔티티이다.A와 B는 일대다, 다대일의 양방향 의존성을 가진다.B는 A를 통해서만 조작될 수 있다.이 때 B를 생성하거나 업데이트 할 때 B의 repository는 어디에 존재해야 하는가?@Entity public class A { @OneToMany(mappedBy = "media", cascade = CascadeType.ALL, orphanRemoval = true) private List<B> bs = new ArrayList<>(); public void updateNumber(long n){ this.bs.stream().forEach(b -> b.update(n); } } @Entity public class B { @ManyToOne(fetch = FetchType.LAZY) private A a; private long number; public void update(long n){ this.number = n; } } 이렇게 되어 있다고 할 때 변경 가능성을 생각할 때(물론 엔티티에서 이미 jpa에 기술을 사용하고 있긴하지만) B의 repository를 따로 가지는게 맞나요? 만약 따로 가진다면 B의 repository가 A repository에서 의존하여 처리 되어야 하나요?jpa에 완전 종속적으로 사용하면 B가 따로 repository를 가질 필요 없는데 순수함을 유지하지 하려 하니 이 부분에서 고민이 되네요. 아니면 이런 고민 자체가 잘못된걸까요?   

도메인 모델을 만들기 위해서는 Domain Expert에게서 듣고 배워야 한다고 말씀하셨는데, 이들의 정확한 역할이 잘 이해가 가지 않습니다.온라인 서점을 예로 들자면 제 머리속에 상상되는 Domain Expert는 실제 서점을 운영하는 사장님이 떠오르는데 강의에서는 회사에서 해당 일을 오랫동안 해 오신 분이나, 관련된 시스템을 개발해 본 경험이 있는 시니어 개발자 같은 사람을 Domain Expert라고 말씀 주셨습니다.그렇다는건 Domain Expert 라는 역할은 이 회사가 개발하고 있는 서비스를 가장 잘 알고 있는 사람 (그것이 개발자가 되었든, 디자이너, po와 같은 비 개발자가 되었든)이라고 이해해도 되는 것일까요?

회원 애플리케이션 서비스 테스트 (1) 12:46초 부분EmailSenderMock에 getter 어노테이션이나 메서드가 없는데 어떻게 getTos를 사용하신 걸까요..?

안녕하세요 토비님 궁금한점이 생겨 질문을 남깁니다.예제를 진행하실때 정적팩토리 메서드를 통해 객체를 반환할때생성자를 통하지않고 바로 멤버변수에 값을 넣어 반환하는걸 사용하셨는데 public static Member register(MemberRegisterRequest createRequest, PasswordEncoder passwordEncoder) { Member member = new Member(); member.email = new Email(createRequest.email()); member.nickname = requireNonNull(createRequest.nickname()); member.passwordHash = requireNonNull(passwordEncoder.encode(createRequest.password())); member.status = MemberStatus.PENDING; member.detail = MemberDetail.create(); return member; }이게 가능한 원리는 이해를 했습니다만 AI와 이야기하다보니 아래와 같은 이유를 제시하면서 생성자를 통한 반환을 강력 추천하더라구요부분 초기화 위험: 생성 직후 한동안 불완전 상태일 수 있어요. (중간에 예외가 나면 더더욱)final 을 못 씀: 생성자 밖 대입이 필요하니 final로 못 고정합니다(불변성/스레드 가시성 이점 상실).검증 누락 가능성: 검증/정규화가 흩어지기 쉬움 → 생성자 경로에 모으는 게 안전. 토비님 생각은 어떠하신지 궁금합니다.

안녕하세요 토비님현재 파트1에서는 아직 required 포트에있는 repository 인터페이스를 다른 도메인에서 사용하고 있지 않아서 중복이 발생하고 있지 않지만, 만약 다른 도메인에서도 같은 리포지토리를 사용해야할 경우 어떻게 하면 좋을지 질문드립니다. 제가 생각한건 첨부한 이미지와 같습니다. 도메인별로 각각 required 포트에 MemberFinder 인터페이스를 선언하고 그것을 Adapter layer에서 각각 도메인 별로 구현합니다. 하지만 실제 로직은 Adapter레이어에 있는 MemberRepository를 부르는 역할만 할 뿐입니다 

안녕하세요 토비님. 강의 잘 수강하고 있습니다.아직 강의 초반부만 들었지만, 아주 감명깊게 수강중입니다.혹시 다음강의 오픈은 언제쯤 예상하고 계실까요?

MemberFinder 와 같은 유즈케이스 단위로 통합 테스트를 분리 해서 작성하셨는데 단위 테스트의 경우에는 분리를 어떻게 하시나요? MemberService (Query, Modify) 가 없이는 코드가 작성이 되질 않아서 질문 드립니다.  

안녕하세요. 궁금한게 있어서 질문 드립니다.domain 패키지에 entity를 위치 한다고 했을때 주석이라고 말씀하신 어노테이션 JPA @Entity를 만들어서 Member로 정의그리고 mongo DB도 필요해서 @Document를 정의해서 domain 패키지에 위치 시켜 Member로 정의이처럼 같은 도메인이 서로 다른 DB로 사용 될때 어떻게 도메인으로 정의해야할지 궁금합니다.그리고 이름이 중복되는 현상도 발생하기도 합니다. 그렇다고 OracleMember, MongoMember로 지을수도 없는것같습니다. 제 생각은 Member라는 도메인이 Domain 패지키에 별도로 나와서 adapter 안에 JPA Persistent의@Entity로 정의된 클래스와Mongo Persistent의 @Document로 정의된 클래스가 위치 되어야한다고 생각하는데 어떤 의견이신지 궁금합니다.

안녕하세요 실무에서 헥사고날을 적용 예정 중에 있습니다. 이미 DB 모델링이 되어 있고 하나의 우리 팀 시스템이 아닌 여러 팀의 시스템에서 같은 테이블을 바라보는 경우 헥사고날 적용은 어떻게 해야하는지 궁금합니다. 하나의 애그리거트로 만들 수 없는 여러 엔티티의 조합으로 조회를 할 경우, 예를 들어 백오피스에서 20개 이상의 조건과 각 조건이 여러 테이블에 나뉘어져있어 Join을 걸어야 할 경우의 도메인 모델과 리턴은 어떻게 해야하는지 궁금합니다.

안녕하세요.강의 정말 잘 들었습니다. 강의를 듣다가 궁금한 점이 있어 질문 남깁니다.Member와 MemberDetail을 별도 엔티티로 분리한 기준이 궁금합니다.관계가 1:1인 경우에는 엔티티에 너무 많은 필드가 있는 것이 아니면 하나로 관리하는 게 더 개발 편의성이 좋지 않을까? 하는 생각이 들기도 합니다. 실제로 회원 정보 수정 시에 닉네임, 프로필 주소, 자기소개를 한 번에 변경하도록 구현되어 있어, 두 엔티티가 함께 조회/수정되는 것처럼 보입니다.혹시 조회 성능 최적화를 위해 접근 빈도가 낮은 데이터를 지연 로딩하려는 의도인지, 아니면 회원의 본질적 속성(email, status 등)과 부가 정보(등록일시, 프로필 등)를 개념적으로 구분하기 위한 설계인지 궁금합니다.감사합니다.

안녕하세요 토비님언제나 헥사고날 아키텍처는 무엇이고 이걸 적용한다는 것이 왜 좋고 왜 필요하다는 것인지궁금했습니다. 이번 강의를 통해서 대략적인 흐름 어떻게 적용할 것인지 어떤 방향으로 작업 해야 하는지 살짝 이해할 수 있었습니다 조금 더 이해도를 높이고 싶은데.. 혹시 토비님께서 추천하시는 서적이 있으실까요??

domain 패키지 안에 activate메서드가 있는데 포트 역할을 하는 MemberRegister 인터페이스에 activate메서드가 또 필요한 이유가 어떤건가요??activate는 외부로 공개될 필요가 없는거 아닌가용??