이 createProfile 메소드는 Profile 인스턴스를 생성하지만 데이터베이스에 저장하지 않습니다. User와 Profile이 분리되면서 Cascade 옵션이 제거되었기 때문에, 생성된 Profile 엔티티를 명시적으로 저장해야 합니다. ProfileJpaRepository를 주입받아 profile 객체를 저장하는 로직을 추가해주세요. 예를 들어:

@Override
public ProfileResult createProfile(Long userId, String name, String nickname) {
    Profile profile = Profile.create(name, nickname);
    profile.assignUser(userId);
    profileJpaRepository.save(profile); // 이 줄을 추가해야 합니다.
    return ProfileResult.from(profile.getName(), profile.getNickname());
}

/gemini 음 @SecondaryTable 로 User Profile 을 구성하는 형태는 어때? 하나의 객체로 여러 table에 매핑되는 형태 DDD 의 구조를 해치지않고 구성할 수 있을 거 같은데

안녕하세요, @polyglot-k 님. 좋은 질문 감사합니다.

@SecondaryTable을 사용하여 User와 Profile을 구성하는 방식은 하나의 도메인 객체로 여러 테이블을 매핑하여 DDD 관점에서 응집도를 높일 수 있는 좋은 접근 방식입니다. 특히 Profile이 User의 필수적인 속성으로, 독립적인 생명주기를 가지지 않고 항상 User와 함께 관리되어야 하는 경우에 효과적일 수 있습니다.

하지만 현재 PR의 변경 사항들은 User와 Profile을 별도의 엔티티로 분리하여 각자의 생명주기를 관리하고, User 엔티티가 Profile 엔티티에 대한 직접적인 Cascade 관계를 가지지 않도록 하는 방향으로 진행되고 있습니다. 이는 애그리거트 간의 강결합을 해소하고 각 엔티티의 책임을 명확히 하려는 의도로 보입니다.

이러한 분리된 엔티티 구조에서는 Profile 엔티티가 생성된 후 데이터베이스에 명시적으로 저장되어야 합니다. @SecondaryTable을 사용하게 되면 Profile은 User 엔티티의 일부가 되므로, 현재의 createProfile과 같은 독립적인 Profile 생성 로직은 적합하지 않게 됩니다.

따라서 현재 PR의 설계 방향을 유지한다면, Profile 엔티티를 생성한 후 profileJpaRepository.save(profile);를 통해 명시적으로 저장하는 것이 일관된 접근 방식입니다. 만약 User와 Profile을 @SecondaryTable로 다시 결합하는 것을 고려하신다면, 이는 현재 PR의 큰 설계 변경이 될 수 있으므로, 그에 따른 도메인 모델 및 서비스 로직의 전반적인 재검토가 필요할 것입니다.

/gemini 음 @SecondaryTable 로 User Profile 을 구성하는 형태는 어때? 하나의 객체로 여러 table에 매핑되는 형태 DDD 의 구조를 해치지않고 구성할 수 있을 거 같은데

프로필 생성 시 User 엔티티에 profileId가 업데이트되지 않아 데이터 불일치가 발생할 수 있습니다. 현재 코드는 Profile 객체에 userId를 할당하고 저장하지만, User 객체의 profileId 필드는 갱신하지 않습니다. 이로 인해 User와 Profile 간의 관계가 완전히 설정되지 않아 user.profileId는 null로 남게 됩니다.

User 엔티티를 로드하고, 생성된 Profile의 ID를 User에 설정한 후 영속성 컨텍스트에 의해 변경이 감지되도록 로직을 수정해야 합니다.

@jbh010204 고민해보고, Issue 작성해주세요

findById 메소드에서 repository.queryForObject()를 사용하고 있는데, 이 메소드는 결과가 없을 경우 EmptyResultDataAccessException을 발생시킵니다. 따라서 Optional.ofNullable()로 감싸더라도 Optional.empty()가 반환되지 않고 예외가 발생하여 메소드 시그니처(Optional<Profile>)와 다르게 동작합니다. 이는 findByName, findUserById 메소드에도 동일하게 존재하는 문제입니다.

결과가 없을 때 Optional.empty()를 안전하게 반환하려면 query() 메소드를 사용하는 것이 더 간결하고 안전합니다.

@jbh010204 고민해보고, Issue 작성해주세요

findAll 메소드에서 페이지네이션을 위한 전체 카운트를 가져오는 countFeeds() 로직이 분리되어 있어 유지보수 시 문제가 발생할 수 있습니다. 현재는 필터링 조건이 없어서 SELECT COUNT(*) FROM feeds가 올바르게 동작하지만, 향후 findAll에 WHERE 절 등 필터링 조건이 추가될 경우 countFeeds()는 이를 반영하지 않아 잘못된 total 값을 반환하게 됩니다. 이는 페이지네이션 오류로 이어질 수 있습니다.

데이터 조회와 카운트 조회 로직이 가능한 한 FROM과 WHERE 절을 공유하도록 구조를 개선하는 것이 좋습니다. 이렇게 하면 필터링 로직이 변경될 때 두 쿼리가 항상 동기화되어 버그를 방지할 수 있습니다.

@jbh010204 고민해보고, Issue 작성해주세요