[🚀 사이클2 - 미션 (예약 변경/취소와 에러 처리)] 루크(이성민) 미션 제출합니다.

[smiinii]

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

베이스 코드 선택 체크

• 이전 미션의 내 코드에서 시작
• 이전 미션의 페어의 코드에서 시작

어떤 부분에 집중하여 리뷰해야 할까요?

1.

이번 사이클 2 기능 중 "관리자는 예약이 존재하는 스케줄을 취소할 수 없다"는 요구사항을 구현하면서, 객체지향 설계 원칙과 의존성 방향에 대해 깊은 딜레마에 빠져 조언을 구하고 싶습니다.
ScheduleService의 delete 메서드에서 스케줄 삭제 전, 해당 스케줄에 엮인 예약이 존재하는지 검증해야 하는 상황이었습니다. 이를 해결하기 위해 아래와 같은 과정을 거쳤습니다.

• 고민 1: ScheduleService ➔ ReservationService 의존
  가장 먼저, 각 도메인의 책임을 존중하기 위해 서비스 간 통신을 고려했습니다. 하지만 ReservationService가 이미 예약 생성 시 ScheduleService를 의존하고 있어 순환 참조가 발생해 애플리케이션 구동에 실패했습니다.

• 고민 2: 파사드 패턴 도입
  순환 참조의 고리를 끊기 위해 상위 계층을 두어 교통정리를 하는 방안도 고려해 보았습니다. 하지만 현재 프로젝트 규모와 기능 대비 클래스가 과도하게 늘어나는 것 같아 다소 오버 엔지니어링이라 판단하여 보류했습니다.

• 현재의 타협안: ScheduleService ➔ ReservationRepository 직접 참조
  결국 순환 참조를 피하면서도 캡슐화를 최대한 지키기 위해, 현재는 두 서비스의 의존 방향과 깊이를 다르게 가져가는 타협안을 선택했습니다.

  • 예약 생성 시 (ReservationService): 유저나 스케줄의 핵심 비즈니스 정책을 침범하지 않기 위해 철저히 UserService와 ScheduleService를 의존하여 단일 책임 원칙을 지켰습니다.
  • 스케줄 삭제 시 (ScheduleService): 순환 참조를 끊기 위해, 복잡한 로직 없이 단순 데이터 존재 여부 조회만 필요한 부분은 타 도메인인 ReservationRepository를 직접 주입받아 existsByScheduleId()를 호출하도록 책임을 완화했습니다.

수달에게 드리는 질문
저는 이런 고민 과정을 거쳐 생성/정책 확인은 Service를 유지하고, 단순 조회는 Repository 참조로 우회하자는 나름의 타협점을 찾게 되었습니다.
수달은 이처럼 완벽한 객체지향 설계 원칙(단일 책임, 계층 분리)과 현실적인 문제(순환 참조, 오버 엔지니어링)가 충돌하는 트레이드오프 상황을 마주했을 때 어떤 기준을 가지고 타협점을 찾으시는지 수달 님의 인사이트가 궁금합니다!!

2. 커스텀 예외 및 에러 메시지 응답의 필요성에 대한 고민

현재 저는 클라이언트가 에러를 쉽게 파악하려면 필요하겠다 정도의 생각으로 커스텀 에러를 도입한 상태입니다. 하지만 단순히 프론트엔드에 띄울 텍스트를 백엔드가 대신 써주는 것 이상의 아키텍처나 유지보수 관점에서의 더 깊은 이유가 있을 것 같다는 생각이 듭니다.
아직 이 부분에 대해 저만의 확고한 기준이 정립되지 않아 질문이 다소 포괄적일 수 있지만 수달은 커스텀 에러 응답을 설계하실 때 어떤 목적을 가장 중요하게 생각하시는지 궁금합니다! 또한 예외를 어느 수준까지 세분화해서 나누시는 편인지 수달의 경험과 인사이트를 꼭 여쭤보고 싶습니다.