feat: 랜딩페이지 입장시 프로젝트의 리더에게만 초대링크를 제공하도록 변경 #334
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- 레포지토리의 getProjectToMember 메서드 파라미터를 project가 아닌 projectId만 받도록 변경 - 서비스의 isProjectMember, isProjectLeader 메서드 파라미터를 project가 아닌 projectId만 받도록 변경 - 서비스 메서드의 변경으로 인해 영향을 받는 컨트롤러 계층의 인수 수정
- getProject 서비스 메서드에서 리더에게만 초대링크를 제공하도록 변경 - getProject의 파라미터가 회원정보를 추가로 요구하기 영향을 받는 메서드 수정 - 클라이언트 API의 DTO인 initLandingDto에서 초대링크 정보가 있을때만 첨부하도록 변경 - 리더에게는 초대링크가 제공되고, 일반 멤버에게는 초대링크가 제공되지 않는것을 확인하는 E2E테스트 추가
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🎟️ 태스크
랜딩페이지의 초대링크 API 변경
✅ 작업 내용
🖊️ 구체적인 작업
파라미터 형식 변경
랜딩페이지 입장시 프로젝트의 리더에게만 초대링크를 제공하도록 구현
🤔 고민 및 의논할 거리
이 변경사항을 컨트롤러에 적용할지, 서비스에 적용할지 고민했습니다. 컨트롤러에 적용할 경우 간단하게 DTO클래스에서 "팀장이면 inviteLink를 프로퍼티로 추가한다" 논리를 넣어서 간단하게 구현할 수 있고, 서비스에 적용할 경우 기존에는 getProject가 프로젝트 ID만 매개변수로 사용하는 반면, 이 로직을 구현하기 위해서는 회원정보도 매개변수로 받아야 해 메서드 시그니처 자체가 바뀌는 불편함이 있습니다. 특히 getProject는 여러 컨트롤러가 사용하기 때문에 변경이 확산되게 됩니다.
하지만 구현의 불편함보다는 컨트롤러계층에 적용했을때의 얻는 단점이 더 크다고 판단해 서비스 계층에 적용하기로 결정했습니다. API가 변경되면 컨트롤러 계층에서의 구현이 바뀔텐데 이로 인해 자칫 잘못하면 리더가 아닌 회원에게도 쉽게 초대링크가 노출될 것이라고 판단했습니다.
이 케이스를 조금 더 일반화해 이야기하면 "표현계층에 비즈니스로직을 넣으면 비즈니스 로직이 표현 계층의 변화에 의해 쉽게 변경될 가능성이 있고, 이러한 형태는 바람직하지 않기 때문에 서비스 계층에 비즈니스 로직을 구현했다"입니다. 감사합니다~