[Main Project] 내가 적용한 기술 설명

 JWT 및 부가기능 (통합서비스 사용)

 

1. 도메인 분리

• 도메인의 연관관계를 최소화 하기위해서 각 도메인의 연관관계를 최소화 하기 위해 다 끊어내고 정말
• 연관성이 깊은 도메인에만 연관관계를 사용해서 N+1, 무한 참조같은 소스낭비나 오류로부터 미연에 방지

 

2. JWT 구현

• JWT Interface 를 통해서 secret key, expiration_time, Header 값을 설정해서 추후에 변경이 있을 때 손쉽게 수정, 관리할 수 있게 구현
• 토큰에는 id, email, username만 포함하여 유출시 위험성을 방지함
• 회원과 기업의 권한을 분리해서 로그인 후 토큰에 부여된 권한내에서 각 URL에 접근할 수 있도록 함

 

3. 좋아요 기능

• 게시물 postID와 일반 회원의 usersId를 필드값으로 가지는 클래스를 생성
  • 현재 로그인 된 유저의 Authentication 토큰 값을 통해 usersId확인
  • 해당 게시물의 postsId를 받음
• 통합 서비스 (PostsService, UserService)를 포함하는 service Class
  • 통합 서비스를 통해 각 서비스에 접근
    • PostsId & UserId 두 값 모두 일치하는 데이터가 없으면 좋아요를 추가
    • 그렇지 않고, 이미 존재하면 좋아요를 취소

최종적으로 한 유저가 한 개의 포스터에 대해 단 한번만 추가할 수 있으며, 반복 클릭시 좋아요/ 취소가 반복된다.

 

4. 통합 서비스 클래스 (lntergrated Service Class), DTO Class 생성

: Service Class 와 DTO Class 를 필요에 따라 최대한 많이 분리하려고 노력했다. 분리함으로써 코드가 무거워지는 것을

방지할 수 있고, 복잡한 관계를 분리함으로써 유지보수에 훨씬 용이하다.

---

자세한 설명

 

 

1. 도메인 분리를 통한 연관관계 단순화

(변경 전) ERD 구조 (변경 후) ERD 구조

 

변경 전 ERD 구조는 모든 테이블간에 1대다 혹은 1대1의 연관관계가 전체적으로 이어져 있습니다.

위 경우 n+1 문제가 쉽게 발생할 수 있고, ERD 구조가 복잡해서 원하는 의도를 제대로 파악할 수 없습니다. 이때 JPA 잘 통제하지 못하면, 한개의 도메인을 조회했을 때 모든 도메인이 한꺼번에 조회되는 경우가 발생 될 것입니다. 이를 보완할 수 있는 방법으로 fetch 전략 또는 fetch join 등 여러가지 방법이 있겠지만, 미연에 설계를 통해 방지하고, 추후에 발생하는 문제에 대해서 접근하는 것이 맞다고 생각했습니다.

따라서 변경 후 ERD 구조처럼 전체적인 도메인을 분리하고, 꼭 필요로 하는 도메인의 경우에만 연관관계를 설정했습니다. 이제는 한눈에 봐도 연관관계가 있는 도메인을 알아보기 쉽게 구성되었습니다.

 

2. JWT 적용

JWT 토큰을 선택한 이유

• 확장성이 좋다.
• 범용적으로 쓰이고 있으며, 참고할 수 있는 자료가 많다는 점.
• 토큰인증 방식을 사용하면, 세션과 달리 클라이언트에 저장하기 때문에 서버의 부담을 줄일 수 있는 점

등의 이유로 선택하게 되었습니다.

JWT 토큰 세팅

• JWT Interface 생성해서 secret key, 만료시간 등 설정하고 추후에 변경이 있을 때 손쉽게 수정, 관리할 수 있게 구현
• 토큰 payload에는 id, email, username, roles만 포함하여 유출시 위험성을 방지했습니다.
• refresh 토큰은 따로 발급하지 않고, access token만 발급하도록 설정 했습니다.

JWT 토큰 방식을 사용하면서 개인회원과 기업회원 각각 회원가입/ 로그인 기능을 구현하는데 어려움이 있었는데, 위와 같은 로직으로 개인회원과 기업회원의 동시에 적용할 수 있는 개념을 제안했습니다.

API를 나누어 호출함으로써 각각 다른 역할을 부여하는 것이 가능해 졌습니다.