feat(health): HealthCondition CRUD 및 테스트코드 구현

[YoungHoney]

🎯 PR 타입

• Feat: 새로운 기능 추가

• Fix: 버그 수정

• Docs: 문서 수정

• Style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우

• Refactor: 코드 리팩토링

• Test: 테스트 코드 추가 또는 리팩토링

• Chore: 빌드 부분 혹은 패키지 매니저 수정

📌 관련 이슈

Related Issue: BS-35

📝 개요
작업 배경 (Why)
사용자의 건강 정보를 체계적으로 관리하고, 이를 기반으로 맞춤형 서비스를 제공하기 위한 기반을 마련합니다. 기존에 분산되어 있던 HealthSummary, RiskAnalysis 등의 모듈을 폐기하고, 명확한 HealthCondition
마스터 데이터와 사용자와의 매핑 관계(UserHealthCondition)를 중심으로 도메인을 재설계했습니다.

• 핵심 변경 사항 (What):
  • HealthCondition (질병, 알레르기 등 건강상태 마스터 데이터)에 대한 CRUD API를 구현했습니다.
  • UserHealthCondition (사용자와 건강상태의 연관 관계)에 대한 CRUD API를 구현했습니다.
  • 각 계층(Controller, Service, Repository)에 대한 단위 및 통합 테스트 코드를 작성하여 기능의 안정성을 확보했습니다.

✅ 작업 상세 내용

• HealthCondition, UserHealthCondition 엔티티 및 Repository, Service, Controller 기본 구조 구현
• HealthCondition, UserHealthCondition 관련 DTO 및 Custom Exception 클래스 추가
• UserHealthCondition 엔티티에 update 로직 추가 및 서비스 계층에 반영
• HealthCondition 및 UserHealthCondition의 Repository, Service, Controller 테스트 코드 작성 및 보강
• 기존 HealthSummary, RiskAnalysis 등 불필요해진 관련 모듈 삭제

📸 결과 및 테스트 방법

• 실행 결과:

  • HealthCondition 및 UserHealthCondition에 대한 CRUD API 엔드포인트가 정상적으로 생성되었습니다.

• 테스트 방법:

  1. 애플리케이션 실행 후 Swagger UI (/swagger-ui/index.html)에 접속합니다.
  2. HealthConditionController와 UserHealthConditionController가 추가된 것을 확인합니다.
  3. HealthConditionController 테스트:
     • POST /api/v1/health-conditions: "당뇨", "고혈압" 등 마스터 데이터 생성
     • GET /api/v1/health-conditions/{id}: 생성된 데이터 단건 조회
     • GET /api/v1/health-conditions: 전체 목록 조회
     • PATCH /api/v1/health-conditions/{id}: 데이터 수정
     • DELETE /api/v1/health-conditions/{id}: 데이터 삭제
  4. UserHealthConditionController 테스트:
     • POST /api/v1/user-health-conditions: 특정 사용자와 특정 건강상태를 연결
     • GET, PATCH, DELETE 등 나머지 API가 정상 동작하는지 확인

짚 리뷰어 집중 포인트

• health 도메인의 새로운 구조가 프로젝트의 다른 도메인과 잘 통합될 수 있는지 확인 부탁드립니다.
• User - UserHealthCondition - HealthCondition 간의 연관관계 설정이 올바른지 검토 부탁드립니다.
• 새로 추가된 테스트 코드(repository, service, controller)가 충분한 엣지 케이스를 커버하고 있는지 확인 부탁드립니다.
  ⚠️ 위험 요소 및 고려사항

• 롤백 계획: 이 PR을 Revert하고 main 브랜치를 재배포합니다.
• 의존성 변경: 없음

롤백 계획 (Rollback Plan)

의존성 변경 (Dependency Changes)

🤖 AI 참고사항 (for AI)

• Scope: src/main/java/com/babsim/babsimbackend/domain/health/, src/test/java/com/babsim/babsimbackend/domain/health/
• Logic: HealthConditionService.java, UserHealthConditionService.java
• Prompt: 다음 작업으로, 사용자의 건강상태(UserHealthCondition)를 기반으로 식단 추천 시 특정 음식을 제외하거나 우선순위를 조정하는 로직을 recommendation 도메인에 구현해줘.

✅ PR 제출 전 체크리스트

• PR 제목은 Conventional Commit에 맞게 작성했습니다.

• main 브랜치로부터 최신 코드를 반영했습니다. (rebase)

• 스스로 코드 리뷰를 진행했습니다.

• 변경 사항에 대한 테스트를 완료했습니다.

• 관련 Jira 이슈를 연결했습니다.

• Assignees, Reviewers, Labels를 올바르게 설정했습니다.

[Ji-Un-Gil]

AI의 피드백 중 생각해 볼만한 부분이 있어서 가져왔습니다. 제가 맡은 부분이었던 diet 도메인의 service 구현을 AI에게 작업시켰을 때, 순환 참조 및 도메인 결합도 등의 문제로 facade 패턴을 사용하여 구현했는데 이 부분에 대해 health 도메인에서도 적용을 추천하는 것으로 보입니다.

LGTM🥳

---

HealthConditionService와 UserHealthConditionService 모두 역할에 맞게 잘 구현되어 있습니다. UserHealthConditionService에서 User와 HealthCondition 엔티티를 조회할 때 NotFoundException을 던져 처리하는 방식은 명확하고 좋습니다.
다만, UserHealthConditionService가 UserRepository와 HealthConditionRepository를 직접 참조하는 부분은 도메인 간 결합도를 높일 수 있습니다. 지금은 구조가 복잡하지 않아 큰 문제가 아니지만, 향후 확장을 고려한다면 UserHealthConditionService의 메서드가 엔티티 ID 대신 User와 HealthCondition 엔티티 객체를 직접 파라미터로 받도록 시그니처를 변경하는 것을 고려해볼 수 있습니다.

// AS-IS
public UserHealthConditionResponse create(UserHealthConditionCreateRequest request) {
    User user = userRepository.findById(request.userId())
        .orElseThrow(UserNotFoundException::new);
    // ...
}

// TO-BE (Facade 패턴 등과 함께 사용)
public UserHealthConditionResponse create(User user, HealthCondition healthCondition, String memo) {
    // ...
}

이렇게 하면 UserHealthConditionService는 health 도메인에만 집중할 수 있게 되며, 사용자 조회 등의 책임은 UserService나 상위의 Facade 계층으로 위임할 수 있습니다.