도메인이 복잡해짐에 따라 테이블 분리

Accommodation은 제일 중요한 도메인이다.

db 모델링을 할 때는 요구사항을 필요한 것부터 설계했다.

Accommodation과 Reservation을 고도화하면서 늘어난 칼럼이 isOnSale, dicountRate 그리고 테이블로는 discount_policy(start_date와 end_date) 가 있다.

청소요금에 대한 칼럼을 추가하려고 하니

칼럼수가 많아졌다는 생각이 들었다.

청소 요금에 대한 로직을 정리해보자.

1.host가 청소 요금을 정한다.

2.청소 요금을 숙소 예약 비용에 추가로 청구한다.

이용자가 하루만 머문 경우와 12일을 머문 경우 동일한 청소 요금을 받는 것이 맞을까?

host가 판단해야 할 영역이다.
host가 숙박 시설의 청소 요금, 청소요금 청구 주기를 직접 정하도록 설계를 변경했다.

그렇다면,
청소 요금과 관련된 테이블을 숙소에서 분리하는 게 나을까?

1)숙소와 청소 요금은 변경 주기가 다르기 때문에 분리를 하는 것이 낫다.

2)물가가 올라서 많은 host가 청소 요금을 바꾼다면, 많은 숙소의 데이터가 변경돼야 한다. 그럴 바엔 참조를 통해서 관리를 하는 게 실수의 여지를 줄일 수 있다.

3)다른 부가 요금들이 추가된다면 별도의 '부가 요금' 테이블로 관리하는 것이 더 나을 수 있다.

이 테이블에 serviceCharge와 관련된 테이블을 추가하기로 했다.

여기에는 어떤 타입의 service인지를 넣을 수 있는데
이건 jpa의 enum타입을 써서 정해진 타입의 데이터를 넣을 수 있도록 했다.