[refactor] kakaoLogin 트랜잭션에서 외부 API 통신 분리하기

[RumosZin]

논의 포인트

#51 을 해결하면서, 이미지 생성 완료 트랜잭션에서 이메일 전송 로직 분리를 마쳤습니다. 그리고 현재 카카오 로그인 트랜잭션에서 "https://kauth.kakao.com"와 통신하는 부분을 분리하려고 하는데, 고민이 있어 공유합니다.

현재 구조

그림으로 간단히 클래스 의존 관계를 표시했습니다. 제가 처음에 생각했던 방안은 다음과 같아요!

1. AuthFacadeServiceImpl을 AuthServiceImpl 앞 단에 두어서 인터페이스 AuthService의 구현체를 AuthFacadeServiceImpl가 되게 한다.
2. AuthServiceImpl은 레포지토리와 가장 가까운 서비스로, UserRepository, TokenRepository에 저장하는 업무를 수행하고 이것은 트랜잭션으로 묶인다.
3. 즉, AuthFacadeServiceImpl에서 Provider 세 개에 대한 처리를 하고, AuthServiceImpl에서는 레포지토리 관련 임무만 수행한다.

현재 코드 상에서 위 123을 구현하려고 하니 kakaoProvider, OIDCProvider만 깔끔히 분리가 가능하고 UserRepository-JwtProvider-TokenRepository는 순서대로 의존성이 있어서 JwtProvider를 따로 떼어내기 어려운 상황입니다.

정확히는,

• userRepository 저장 코드는 kakaoIDTokenPayload에서 가져온 값으로 수행하는 것이라 분리가 가능
• 이후 JwtProvider가 refresh_token 발행-TokenRepository는 이것을 저장-JwtProvider가 TokenRepository에 저장된 내용으로 access_token 발행하는 구조
• JwtProvider를 TokenRepository와 분리할 수 없다!는 결론이 나왔습니다.

결론

이런 의존관계를 없앨 수 있는 방법이 있을까요? 혹은, JwtProvider는 트랜잭션에서 분리하지 않아도 괜찮을까요?
그림에서 1번만 트랜잭션에서 분리하고, 234는 트랜잭션에 묶이도록 하는 것이, Facade 객체를 이용해 외부 통신 API를 분리하는 작업의 의미를 상실하게 하진 않을지 고민이 됩니다.

[win-luck]

그림에서 1번만 트랜잭션에서 분리하고, 234는 트랜잭션에 묶이도록 하는 것이, Facade 객체를 이용해 외부 통신 API를 분리하는 작업의 의미를 상실하게 하진 않을지 고민이 됩니다.

2~4 중 하나만 없어도 의미를 잃어버리는 구조라고 생각합니다. JwtProvider 자체가 주체적인 객체라기보단 어디까지나 "도구"인 만큼 우려하지 않으셔도 될 것 같습니다.

[tthisag246]

제가 디자인 패턴 관련 지식이 많이 부족해서 facade 객체를 어떻게 활용할지에 관해서는 의견을 말씀드리기 어려운 점 양해 부탁드립니다 .... 해당 이슈를 읽고 구글링하면서 찾아보았으나 실제로 어떻게 적용해야할지 감이 안 잡히네용 🥲

그래서 JwtProvier와 TokenRepository를 분리하는 방법에 대해서만 말씀 드리자면, 둘을 분리하기 위해선 access_token의 payload에 refreshId가 들어가지 않도록 토큰 구조를 변경해야 할 것 같습니다. 그러면 TokenRepository에서 access_token에 해당하는 refresh_token을 찾는 방법도 변경되어야 하는데, TokenRepository에 refresh_token과 access_token을 함께 저장하고 access_token으로 검색하는 방식을 사용하면 될 것 같습니다.
이렇게 토큰 구조를 변경하고 코드 순서를 다음과 같이 변경하면 JwtProvier 도 분리가 가능할 것 같습니다.

1. KakaoProvider, OIDCProvider
2. JwtProvider - refresh_token, access_token 발행
3. UserRepository 저장
4. TokenRepository 저장

아니면 위에 승운님 말씀대로 JwtProvider를 그냥 도구로 생각하고 신경쓰지 않는다면, ~Util 등으로 네이밍을 변경하는 건 어떨까 싶습니다..!