[🚀 사이클2 - 미션 (예약 변경/취소와 에러 처리)] 바니(임혜정) 미션 제출합니다.

[frombunny]

안녕하세요~ 웨지!
리뷰를 소화하는 시간을 오래 가져가고 싶어서 가능한 빠르게 구현을 해보았습니다..ㅎㅎ
이번 리뷰도 잘 부탁드립니다 🙇‍♂️

아직 부족한 부분이 많습니다. 편하게 피드백 주시면 감사히 반영하겠습니다 🐰
요즘 일교차가 크니 감기 조심하세요 !!

프론트 단을 제외한 커밋 범위 : 3948283 ~ 9517feb
+) 제가 키보드가 문제인지 커밋 메시지 마지막 글자가 하나씩 잘리더라구요 ㅠㅠ
그런데 이미 push된 커밋들의 해시를 최대한 유지하고 싶어서 수정은 하지 못했습니다..!!
혹시 커밋 메시지가 어색해 보이더라도 양해 부탁드립니다 🙇‍♂️

체크 리스트

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

베이스 코드 선택 체크

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

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

1. Soft Delete

예약/시간/테마의 삭제를 실제 물리 삭제가 아니라 “비활성화” 개념으로 보고 구현했습니다!
특히 예약 내역은 이후 조회나 이력 확인 등에 사용될 가능성이 있다고 생각해서 데이터를 완전히 제거하지 않는 방향을 선택했습니다.

1-(1) 소프트 딜리트 위치(Service vs Repository)

그래서 현재는 soft delete 자체를 단순 persistence 처리보다는 비즈니스 규칙에 가까운 개념으로 보고 있습니다.

이 관점 때문에 “삭제 정책” 자체는 Service 계층의 책임으로 보고, 실제 DB 반영만 Repository가 수행하도록 구성하고 있는데, 이런 역할 분리가 일반적으로도 자연스러운 구조인지 궁금합니다.

1-(2) Soft Delete와 HTTP Method 선택

현재 삭제 API는 DELETE 대신 PATCH 메서드로 구현했습니다.
이유는 실제로 데이터를 제거하는 것이 아니라, “활성 상태를 변경한다”는 개념에 더 가깝다고 생각했기 때문입니다.
즉 현재 구조에서는 삭제를 “리소스 제거”보다는 상태 변경으로 해석하고 있는데, 이런 경우 PATCH 메서드를 사용하는 방향도 괜찮은 접근인지 궁금합니다 🐰

2. 실제 테스트를 얼마나 작성하시는지

현재는 학습 과정이다 보니 가능한 한 테스트 커버리지를 높게 가져가려고 하고 있고, 비즈니스 로직은 라인 단위로 최대한 검증하려고 노력하고 있습니다. 제가 테스트를 짜본 경험이 많이 없는 만큼, 최대한 꼼꼼하게 짜면서 연습하고자 하는 마음입니다!
그러다 보니 실제로는 메인 코드보다 테스트 코드 작성에 더 많은 시간이 들어가는 경우도 꽤 많았습니다 😅
다만 문득 궁금해진 점이, 보통 이 정도 수준으로 테스트를 세세하게 작성하는지 궁금합니다..!!
실제로 회사에서는 어느 정도 수준까지 테스트를 작성하는 편인지, 또 최근에는 AI를 활용해서 테스트를 작성하거나 보조받는 문화도 많이 있는지 알고 싶습니다!

3. Reservation / ReservationTime / Theme 책임 분리 고민

지난 사이클에서 피드백 주신 부분을 반영하였습니다!
현재 구조에서는 Reservation, ReservationTime, Theme가 모두 예약 기능 안에서 함께 사용되다 보니, 책임 경계가 조금 애매하게 느껴지고 있습니다. 특히 예약 가능 여부 판단처럼 여러 도메인의 데이터를 함께 사용하는 로직이 생기면서, 어느 객체/서비스가 해당 책임을 가지는 것이 자연스러운지 계속 고민하게 되었습니다.

처음에는 Aggregate Root 형태로 강하게 묶는 구조도 고민했지만, DDD 기반 모델링은 오히려 도메인 경계를 잘못 설정하면 복잡도만 높아질 수 있다고 느꼈습니다. 특히 현재 규모에서는 과한 모델링이 될 수도 있다고 판단해서, 우선은 각 도메인이 자신의 상태와 규칙을 최대한 가지되 여러 도메인을 조합하는 흐름은 Service에서 조율하는 방향으로 구성하고 있습니다.

어떻게 하면 책임 경계를 잘 나눌 수 있을까요? 😢