Service에서 다른 Service 의존 vs 다른 Repository(Dao) 의존
- 비즈니스 제약사항의 사용이 필요하다면 (일반적으로 CUD)Service, 그렇지 않다면 Repository (일반적으로 Read)!
- 파사드 패턴
- 어디쪽인지 모호한 친구들 → 묶어서 더 상위 레이어 만든다.
- 레퍼런스
- 추가 궁금증) 컨트롤러에서 여러 서비스들 의존하는 구조는 왜 나쁜가? 트랜잭션 전파가 안일어나나? 기존 police 레거시 구조가 이렇게 되어 있는데 바꿀 합당한 이유 찾기!
CICD
- 오랜만의 cicd 구축! 이번이 6,7번째 cicd 구축이었는데 예전과 달리 정말 수월하게 구축할 수 있었다.
- 에러 요인 : 보안 그룹 8080 안열어뒀었고, docker build할 때 경로를 dockerfile이 있는 곳에서 하지 않았음. private key로 openSSH 주는 거 까먹고 ppk 넣음.
- 2트만에 성공!
AccessToken 재발급 로직
- 먼저 깃허브를 탐방해 다른 프로젝트 코드들을 보면서 로직을 정리해보자.
- 1번) 두둥 : Token Entity: refreshToken, user / token: id
- refreshToken으로 db에서 Token Entity 찾기
- Token Entity의 refreshToken을 파싱해서 id 찾기
- id로 db에서 User Entity 찾기
- User Entity의 oauthInfo로 재로그인 시키기
- User Entity로 accessToken 재생성하기
- 2번) 아띠즈(내 플젝) : Token Entity: refreshToken, user / token: loginId, role
- refreshToken으로 db에서 Token Entity 찾기
- Token Entity의 refreshToken을 파싱해서 expiration 찾기
- 만료 시간이 지니지 않았으면 refreshToken 속 내용으로 accessToken 재생성하기
- 만료 시간이 지났으면 TOKEN_EXPIRED 에러 내보내기
- 3번) 비치컴바인 (내 플젝) : Token Entity: refreshToken, user / token: loginId
- refreshToken 유효한지 확인
- refreshToken 파싱해서 loginId 찾기
- loginId와 refreshToken으로 db에서 Token Entity 찾기
- loginId로 db에서 Member Entity 찾기
- 4번) 아이러빗(회사 다른 플젝) : Token Entity: refreshToken, accessToken, user / token: id