[FEAT] 9주차 미션_오아시스 - #42
Conversation
wldmsdl7
left a comment
wldmsdl7
left a comment
There was a problem hiding this comment.
코드 대부분 비슷해서 크게 리뷰할 건 없었던 것 같아 !
그래도 궁금한 점 하나 남겼으니 확인해줘 ~ 수고했어 ! 👏🏻👏🏻
| @Override | ||
| public boolean isAccountNonExpired() { | ||
| return true; | ||
| } | ||
|
|
||
| @Override | ||
| public boolean isAccountNonLocked() { | ||
| return true; | ||
| } | ||
|
|
||
| @Override | ||
| public boolean isCredentialsNonExpired() { | ||
| return true; | ||
| } | ||
|
|
||
| @Override | ||
| public boolean isEnabled() { | ||
| return member.getIsEnabled(); | ||
| } |
There was a problem hiding this comment.
오 현재 사용자 상태도 함께 표현해준 것 좋은 것 같다 ! 굿굿
There was a problem hiding this comment.
Home 이랑 Member 도메인을 나눈 이유가 궁금해 !
같은 member 도메인이면 컨트롤러를 하나로 둬도 되지 않나 ? 오아시스의 생각이 궁금하넹 ~
There was a problem hiding this comment.
이 부분은 스터디 초반 api 설계때 했던 고민이 이어지는건데, 먼저 홈 화면 데이터를 어떻게 내려줄지 고민했어
각 도메인의 API를 클라이언트가 여러 번 호출해서 조합하게 하거나, 서버에서 홈 화면에 필요한 데이터를 한 번에 조합해서 내려주거나 이 두 개의 방식중 선택을 해야하는데,
나는 이중 후자가 더 적절하다고 생각했어. 이유는 홈 화면은 화면 진입 시 필요한 데이터가 정해져 있고, 클라이언트가 여러 API를 호출해서 조합하는 것보다 서버에서 한 번에 내려주는 편이 클라이언트 구현도 단순하고 응답 구조도 관리하기 쉽다고 생각했거든.
그 다음에 고민한 게, 이 홈 화면 API를 어느 컨트롤러에 둬야하지?
home 이라는 리소스는 여러 도메인의 데이터가 조합된거라 하나의 도메인으로 보기에는 애매했고, 어쨌든 우리가 도메인형 아키텍처로 설계를 하고있기 때문에 굳이 특정 도메인에 속해야 한다면,
홈 화면은 특정 member를 기준으로 조회되는 데이터이기 때문에 member 도메인 안에 두는게 제일 자연스럽다고 생각했어.
다만 응답 안에는 mission과 같은 다른 도메인의 데이터도 포함되기 때문에, MemberController에 넣으면 단일책임원칙을 위배하는 설계라고 생각했어. 그래서 도메인은 member 안에 두되, 역할과 책임을 분리하기 위해 HomeController를 따로 둔 거야.
There was a problem hiding this comment.
홈 화면은 보통 여러 도메인의 데이터로 구성되잖아? 오아시스 말대로 각 도메인의 API를 클라이언트가 따로 호출해서 조합하게 하면, 클라이언트 쪽 복잡도가 올라갈 수 있다고 생각해. 로딩 상태도 각각 관리해야 하고, 일부 API가 실패했을 때 어떻게 보여줄지도 프론트에서 신경 써야 하니까.
지금 홈 화면에서 노출되는 정보는 간단해서 오아시스처럼 한 번에 내려줘도 괜찮을 것 같아! 다만 나중에 각 섹션이 무거워지면(뭐 위치기반 미션 추천 섹션, 이미지와 함께 미션을 조회 등등이 추가될 수도 있겠지?) 그때는 분리를 고려해볼 것 같다!
서비스 메서드는 특정 멤버의 홈 화면이니까 멤버서비스 안에 두고, 컨트롤러만 클래스 레벨로 분리해줬구나. 멤버 도메인 안에 둔 이유를 이렇게 설명할 수 있게 설계한다면 팀원들이 충분히 납득가능할듯!!
다만 한 가지 더 생각해볼 수 있는 부분은 어떤 기능이 특정 멤버를 기준으로 동작한다고 해서 항상 MemberService의 책임이라고 보기는 어렵다는 점인 것 같아..! 예를 들어 auth도 회원과 밀접하게 관련되어 있지만 인증이라는 별도 책임이 있어서 member와 분리해서 다루잖아? 홈도 auth만큼 독립적인 도메인은 아니지만, member, mission, point 같은 여러 데이터를 조합하는 화면 조회용도라면 HomeQueryService처럼 따로 분리하는것도 난 고려해볼거같아. 오아시스도 한번 고민해보면 좋을듯!!
There was a problem hiding this comment.
오아시스 이거 관련해서 요런 레퍼런스도 있어서 읽어보면 좋을거같아!
https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends
| url: ${DB_URL} | ||
| username: ${DB_USER} | ||
| password: ${DB_PW} |
There was a problem hiding this comment.
.env 에서 환경변수 받아오는 방식으로 수정한 점 잘한 것 같다 ! 👍🏻👍🏻
gyeonseo
left a comment
gyeonseo
left a comment
There was a problem hiding this comment.
오아시스 JWT 기반 회원가입, 로그인은 잘 구현해준거같아서 고봉밥으로 써준 댓글에 고봉밥 코멘트 남겼어!! 오아시스는 이런 관점을 가지고 개발하는거같아서 너무 좋네~ 기술블로그도 항상 열심히 써주고,, 앞으로도 화이팅이야!
There was a problem hiding this comment.
홈 화면은 보통 여러 도메인의 데이터로 구성되잖아? 오아시스 말대로 각 도메인의 API를 클라이언트가 따로 호출해서 조합하게 하면, 클라이언트 쪽 복잡도가 올라갈 수 있다고 생각해. 로딩 상태도 각각 관리해야 하고, 일부 API가 실패했을 때 어떻게 보여줄지도 프론트에서 신경 써야 하니까.
지금 홈 화면에서 노출되는 정보는 간단해서 오아시스처럼 한 번에 내려줘도 괜찮을 것 같아! 다만 나중에 각 섹션이 무거워지면(뭐 위치기반 미션 추천 섹션, 이미지와 함께 미션을 조회 등등이 추가될 수도 있겠지?) 그때는 분리를 고려해볼 것 같다!
서비스 메서드는 특정 멤버의 홈 화면이니까 멤버서비스 안에 두고, 컨트롤러만 클래스 레벨로 분리해줬구나. 멤버 도메인 안에 둔 이유를 이렇게 설명할 수 있게 설계한다면 팀원들이 충분히 납득가능할듯!!
다만 한 가지 더 생각해볼 수 있는 부분은 어떤 기능이 특정 멤버를 기준으로 동작한다고 해서 항상 MemberService의 책임이라고 보기는 어렵다는 점인 것 같아..! 예를 들어 auth도 회원과 밀접하게 관련되어 있지만 인증이라는 별도 책임이 있어서 member와 분리해서 다루잖아? 홈도 auth만큼 독립적인 도메인은 아니지만, member, mission, point 같은 여러 데이터를 조합하는 화면 조회용도라면 HomeQueryService처럼 따로 분리하는것도 난 고려해볼거같아. 오아시스도 한번 고민해보면 좋을듯!!
| .accessDeniedHandler(accessDeniedHandler)) | ||
| .addFilterBefore(jwtAuthFilter, UsernamePasswordAuthenticationFilter.class); |
3 participants
🛠️ 작업 사항
📸 관련 이미지 (스크린샷 또는 동영상)
회원가입 한 DB
로그인 테스트
토큰 넣고 private api 접근
💬 기타 설명