엔티티는 record → class로 수정

> 

**대상: 방탈출-회원 예약 싸이클1**

## 문제 인식 — 무엇이 문제였나?

> 현재 코드 혹은 구조에서 느낀 불편함, 버그, 유지보수 어려움 등을 구체적으로 기록하세요.

### 문제 상황

- 도메인 엔티티를 record 자료형으로 사용했을 때의 문제점
1. record를 값 그 자체를 식별자로 갖게된다.

엔티티는 id를 가지는 도메인 엔티티인데 id를 생명 주기로 가지게 된다.
하지만 record는 모든 필드값이 같으면 같은 객체로 equals로 동등성을 비교하게 된다.

그러면 record를 도메인 엔티티로 사용하는게 맞을까 ?
아니다 맞지 않다.

엔티티의 동일성은 식별자 기반이어야 한다. 도메인 객체는 값이 바뀌어도 같은 존재이다.
2. 불변성 문제
record는 완전한 불변 객체이기 때문에 
저장 후에 id를 받고 받은 id로 다시 record를 생성하게 되는데 이것은 도메인의 영역이 아니게 된다.

즉, 값 그 자체가 식별자인 객체는 도메인이 아니고, 
`생명주기와 식별자를 갖는 객체는 class로 설계하는게 맞다.`

### 문제가 되는 코드 / 구조


```plain text
// 문제가 있는 코드나 구조를 붙여넣으세요 (코드가 아닌 경우 텍스트로 설명)
```


### 문제 유형 체크

- [ ] 중복 코드 / 로직
- [ ] 불명확한 이름 (변수, 메서드, 클래스 등)
- [ ] 단일 책임 원칙(SRP) 위반 — 너무 많은 역할
- [ ] 높은 결합도 — 변경 시 여러 곳에 영향
- [ ] 낮은 응집도 — 관련 없는 것들이 한곳에
- [ ] 확장하기 어려운 구조 (OCP 위반)
- [ ] 테스트하기 어려운 구조
- [ ] 성능 문제
- [ ] 가독성 / 이해하기 어려움
- [x] 기타: 엔티티 자료형의 문제

## 변경 이유 — 왜 바꿔야 하는가?

> 지금 당장 동작하더라도 왜 바꾸어야 하는지 그 필요성을 설득력 있게 정리하세요.

엔티티를 record로 사용했을 때,


생명주기와 식별자는 갖는 객체를 record로 설계한다면
값 그 자체가 식별자가 되고 불변 객체인 record의 목적과 맞지 않게 된다.


## 변경 방향 — 어떻게 바꿀 것인가?

> 어떤 방식으로 접근할지, 어떤 기법·패턴·원칙을 적용할지 계획을 기록하세요.

### 접근 전략

- 엔티티에 만든 Reservation, Time, Theme 레코드를 class로 바꾼다.
- equals hashCode를 id 기반으로 재정의 한다.

### 적용할 기법 / 패턴 / 원칙

- [ ] 메서드 추출 (Extract Method)
- [ ] 클래스 / 인터페이스 추출
- [ ] 디자인 패턴 적용 (패턴명: )
- [ ] 레이어 / 모듈 분리
- [ ] 의존성 역전 (DIP) 적용
- [ ] 불변 객체 / VO 도입
- [ ] 기타:

## 회고


### 배운 점

- 엔티티를 record로 사용하면 안되는 이유
- 생명주기와 식별자에 대한 개념