SpaceDetail 관련 로직 정리 #46
Description
📋 개요
저희는 현재 Space가 직접 장소 정보를 가지고 있는게 아니라, 연결된 SpaceDetail을 통해 장소의 세부 정보를 가져오도록 했습니다.
Space는 서비스 전반적으로 사용되는 엔티티지요?
하지만 Space는 SpaceDetail 없이는 존재할 수 없습니다.
그러므로 저희 모두는 SpaceDetail에 대한 이해가 필요하며, 어떻게 설계해야 유지보수가 편할지 고민해 보아야 합니다.
주변 장소를 조회할 때의 로직
사용자가 주변 장소를 조회하고 싶다고 가정해봅시다.
저희는 Google Places Open API에 장소 조회 요청을 보내고, 장소에 대한 상세 정보를 받아옵니다.
그러면 이제 클라이언트 측에 뿌려줄 장소 데이터를 획득한건데, 클라이언트 측에 뿌려주기 전에 해당 데이터들을 SpaceDetail 테이블에 저장해 주어야겠죠?
여기서 상황에 따라 로직이 갈리게 됩니다.
1. 해당 Google Places Identifier에 대한 SpaceDetail이 존재하지 않음
저희가 처음 조회하는 장소라면 SpaceDetail 테이블에 해당 엔티티가 존재하지 않겠죠?
그렇다면 해당 정보를 바탕으로 새로운 SpaceDetail 엔티티를 생성하는 작업을 먼저 수행해 주어야 합니다.
2. 해당 Google Places Identifier에 대한 SpaceDetail이 존재함
저희가 이전에 조회해본 장소라면 space_detail 테이블에 기존 엔티티가 저장되어 있을 것입니다.
하지만 그것은 과거의 정보이므로, 저희는 테이블에 저장된 캐시 데이터를 업데이트 해 주어야 합니다.
그러므로, Google Places Identifier로 조회된 SpaceDetail 엔티티의 값을 수정하는 작업을 먼저 수행해 주어야 합니다.
상황별로 적절하게 SpaceDetail 엔티티를 생성/수정하고 나면, 클라이언트에 장소 정보를 넘겨주면 됩니다.
새로운 Space를 생성할 때의 로직
사용자가 새로운 일정(Schedule)을 저장한다고 가정해봅시다.
사용자는 일정에 대한 정보에 더해, 각 장소에 대한 정보를 Google Places Identifier로 저희에게 넘겨줄 것입니다.
그렇다면 저희는 그 정보를 받아, Space를 생성하고 Google Places Identifer를 통해 각각 SpaceDetail과 연결해주어야 할 것입니다.
여기서 상황에 따라 로직이 갈리게 됩니다.
1. 해당 Google Places Identifier에 대한 SpaceDetail이 존재하지 않음
사실 이 경우는 불가능합니다.
프론트 측에서 저희에게 건네준 Google Places Identifier는, 저희가 이전에 조회해서 프론트에 뿌려준 Google Places Identifier일 것입니다.
그러므로, 프론트 측에서 저희가 모르는 Google Places Identifier를 전달할 가능성은 없습니다.(있으면 버그입니다)
이 경우는 생각하지 않아도 될 것 같네요.
2. 해당 Google Places Identifier에 대한 SpaceDetail이 존재함
저희가 찾는 SpaceDetail이 존재하지 않는 경우가 없으니, 이러면 처리가 간단하겠죠?
Google Places Identifier를 기준으로 DB의 space_detail 테이블에 조회 쿼리를 날려 SpaceDetail 엔티티를 하나 찾아오면 되겠네요.
그렇게 찾은 엔티티를 저희가 새로 만들 Space 엔티티에 연결해 주면 됩니다.
기존 Space를 조회해야 할 때의 로직
AI로부터 장소 정보를 받을 때를 제외하곤, 별도의 캐시 업데이트를 하지 않는 것으로 변경했습니다.
사용자가 이전에 만들어 둔 일정(Schedule)을 조회하고 싶다고 가정해 봅시다.
저희는 일정에 대한 정보 뿐 아니라, 일정 안에 있는 Space에 대한 정보까지 모두 뿌려줘야 합니다.
즉, 다음과 같이 동작해야 합니다.
Space를 조회한다.Space에 연결되어 있는SpaceDetail을 조회한다.- 조회한
SpaceDetail의 정보를 클라이언트에 전달한다
SpaceDetail 관련 로직을 처리할 클래스를 따로 만들자(취소)
AI로부터 장소 정보를 받을 때를 제외하곤, 별도의 캐시 업데이트를 하지 않는 것으로 변경했습니다.
그러면 저희는 AI로부터 장소 정보를 받을 때만 캐시를 업데이트해주면 되니, 별도의 클래스가 필요하진 않을 것 같습니다.
AI로부터 장소 정보를 받아오는 클래스에서 한번에 처리하면 될 것 같습니다.
저희는 장소에 대한 캐시 데이터를 새로 갱신해주는 작업을 해 주어야 합니다.
그래서 이 작업을 수행해줄 클래스를 하나 만들어 두면 좋겠습니다.
1. 주변 장소 조회 시 동작할 메서드
저희는 주변 장소를 조회하면, Google Places Open API로부터 최신의 정보들을 받아오지요?
이 정보들을 space_detail 테이블에 반영해 주어야 합니다.
- 외부(다른 클래스)로부터 호출됩니다.
이 때, 호출되는 메서드는 파라미터로 "장소 상세정보를 담은 DTO 리스트"를 받습니다.
(ex_List<GooglePlaceDto>)
각 DTO에는Google Places Identifier + 장소의 상세정보들이 담겨 있을 것입니다. - 만일 Google Places Identifier로 조회되는
SpaceDetail엔티티가 없다면, 새로 만듭니다.
있다면, 해당SpaceDetail엔티티의 정보를 업데이트합니다. - 로직을 처리하며 생성/업데이트한
SpaceDetail을List형식으로return합니다.