코드 리팩토링 1 - 코드 정리, 가독성 증가

구조 정리

1. 수 많은 dto들의 위치를 정리하였다.

현재 우리의 프로젝트는 MSA 구조이기 때문에, 서로의 동작을 약속하고 개발 과정은 완전히 독립적이다.

남이 보기에도 명확하게, 한눈에 보기 쉽게 DTO를 정리하였다. 

 

2. SERVICE가 아닌 METHOD 단위의 분할을 진행하였다.

변경 전, 각 SERVICE들은 거의 1~2개의 메소드 밖에 포함된게 없었다.

변경후, SERVICE 1개의 범위의 메소드 단위의 기능이 묶였다.

 

설계 과정에서 SERVICE의 범위를 최대한 세밀하게 분리하자는 생각에 따라 각 SERVICㄷ들이 1개의 메소드를 지니게
아주 잘게 서비스를 분할하였는데, 리팩토링 과정에서 해당 과정에 따른 높은 결합도의 문제에 대한 의견을 들었다.

 

전체적인 결제의 검증과 저장을 한 SERVICE로 묶었다.

그럼에도, 고의 적으로 SERVICE를 분할하기도 했다.

 

해당 SERVICE들은 사실 메소드의 개수가 많지 않기 때문에 분할하여도 되었지만, 서비스의 범위 자체가
요청을 보내는 부 , 요청을 받는 부로 다르기 떄문에 SERVICE 단위를 분할하였다. 

 

Builder 패턴의 사용. 

 

1. Setter를 제거할 수 있게 되었다

 

2. 결제에 문제가 생겼을시, 응답을 바로 생성하고 시간을 감소시키자. 

 

 

 

TEST

 

1. MSA과정에 따른 TEST 환경 구축

 

현재 , PRODUCT부에 GCP등의 정보가 있기 때문에, 바로 테스트가 불가능하다.

MEMBER CONTAINER부의 코드를 임의로 변경하여 테스트를 진행해야 한다. 

gcp 관련 기능 주석 처리 . product image와 같은 부는 결제 관련되어 연관이 없기 때문에 가능하였다.

모두 변경 . IMG TEST기능을 완벽히 제거했다.

개인의 CONFIG-SERVER를 구축. 해당 설정에 따라 동작하게 변경

 

2. PORTONE구조에 따른 TEST상의 어려움 해결

 

현재 PORTONE 형식은

1. FRONT에서 결제한다. 2. FRONT에서 PAYMENT_ID를 전송해주면, 해당 내용을 PORTONE에 전송해 결제 내역을 받아온다 . ~~ 의 과정이다 .

 

즉, 실제로 결제 하지 않으면, 검증 TEST조차 불가능하다. 

 

이를 위해 최초에 내가 만들었던 초 간단 FRONTEND단을 활용하여 TEST를 진행하겠다. 

 

간단한, 결제 요청부. (물론 실제 값을 넣어 TEST하였다.)

 

 

즉, 1. Test application으로 결제 2. 완성 service 로직으로 구현 3. Portone 개발자 채널로 확인  

 

portone 토큰 받기

front에서 결제한 pid로 , portone에서 정보 받아오기

 

이제, paymet 정보를 portone에 저장시켰다. 
이 pid를 넣어, postman으로 요청을 보내면 실제 결제 요청을 테스트할 수 있다. 

 

테스트 성공

 

결제 완료, 테스트 환경을 로컬로 구축했다.

(image는 제거하였으며, gcp 정책과 json key 보호로 인해 개인 레퍼지토리를 private로 관리)

// 다음 테스트는, 잘못된 요청 시 요청 취소 TEST와 
PORTONE DTO 간료화를 목표로 하겠습니다.