2024-01-15

오늘은 팀프로젝트 12일 차이다.

주말 및 오늘 진행한 내용은 다음과 같다.

 

주말동안 기존에 Entity 수정으로 인해 대부분의 코드가 리펙토링해야 하는 상황이었다. 따라서 주말 동안 리펙토링을 진행하면서 백오피스의 기능을 전부 구현했다.

백오피스의 기능은 다음과 같다. 공연장 생성 API, 공연생성 API, 등급 생성 API, 구역 등급 생성 API 기능을 구현했다. 각각 생성 API가 서로 연관되는 Entity가 많다 보니 뭐를 생성하는지 복잡하기 때문에 정리를 하려고 한다.

정리한 내용은 다음과 같다.

 

1. 공연장 생성 API 에서는 공연장 및 구역 Entity를 생성 및 저장한다. 공연장은 이름 및 주소와 총 좌석 개수를 가지고 있고, 구역은 공연장의 정보 및 공연장의 각 구역 정보와 좌석의 개수 정보가 있다.

 

2. 공연 생성 API에서는 공연 정보와 공연 카테고리, 공연 정보 이미지, 공연 및 회차를 생성한다. 공연정보는 공연에 대한 이름, 공연에 대한 설명과, 연령등급, 러닝타임의 데이터가 있으며, 공연 카테고리는 카테고리정보, 공연 이미지는 썸네일 이미지와 일반 이미지 ex) 배우 이미지 등등의 데이터가 S3와 연동하여 Url로 이미지가 관리된다. 또한 공연 정보는 공연이 열리는 공연장과 공연정보에 대한 데이터가 들어가며, 공연의 시작일과 종료일의 데이터가가 있다.

 

3. 등급 생성 API에서는 공연에 대한 좌석의 등급이 나누어져 있으며 각 등급마다 예약 가격과 경매가격의 데이터를 가지고있다.

 

4. 구역 등급 생성  API는 1번의 공연장에 대한 구역의 정보와 3번의 등급에 대한 데이터를 가지고 있다.

 

위의 내용을 바탕으로 각 API에서는 Entity를 생성 및 DB에 저장을 진행한다. 
이를 통해 클라이언트에서 진행하는 방식은 다음과 같다.

 

1. 클라이언트에서 공연장과 구역에 대한 정보를 기입하고 저장 

 

2. 해당하는 공연장의 정보를 리스트 요청을 받고 공연장 선택 후 공연 생성에 필요한 정보 기입 후 요청

 

3. 해당 공연 정보에 따라 가격 결정을 위한 등급에 필요한 정보 기입 후 요청

 

4. 1, 2, 3번의 요청 응답값을 통해 구역 등급을 생성

 

위의 클라이언트의 행동을 가정하고 생성 API를 구현했다. 따라서 이전글에서 설명했었던 문제인 단일 책임원칙과 확장성 및 재사용성을 위해 Admin Service는 각 도메인의 Service에서 create메서드를 호출하여 생성 및 저장을 진행하여 코드를 작성했고 각 도메인에서 리턴 받은 값을 통해 각각의 연관된 Entity의 정보를 채워나가는 방식으로 진행했다.

 

이러한 방식은 기존에 진행했던 각 도메인의 Service의 Repository 메서드를 호출하여 받은 데이터를 Admin에서 각 도메인의 Entity를 생성하는 방식보다는 코드 작성에 있어서 여러 클래스를 왔다 갔다 하기 때문에 작성하는 데는 시간이 오래 걸리지만 작성하고 보니 가독성 및 유지 보수에 있어서 눈에 띄게 좋아진 느낌이었다.

 

제일 좋았던 점은 여러 도메인에 메서드가 구성돼 있기 때문에 복잡해 보일 수 있지만 오히려 나중에 정보를 찾기가 훨씬 편했고 오류에서 어디가 문제인지 파악하는데 훨씬 도움이 많이 됐다. 이번경험으로 복잡한 연관관계의 구조를 가진 통합 서비스를 구현하는 프로젝트라면 무조건 도메인을 나눠서 기능을 구현할 것이다.