feat: 공동 모임장 구현

[mikekks]

👩‍💻 Contents

• 공동 모임장 기능을 구현했습니다.
• 새로운 엔티티 JointLeader 라는 엔티티가 생겼는데 이름부터 시작해서 한 번 검토해주시면 감사하겠습니다!
• 수정범위 관련 문서 : https://www.notion.so/sopt-makers/a67f826ddf4d401aa25945eb419417f8?pvs=4

모임 상세 조회

내가 만든 모임 조회

📝 Review Note

• 내 모임 조회 로직에서, 공동모임장인 모임들을 불러오는 쿼리 가 필요할 것 같은데 이것까지 넣으면 너무 PR 이 커질 것 같아서 다음 PR에 구현해보도록 하겠습니다!

📣 Related Issue

• closed feat: 공동 모임장 구현 #447

✅ 점검사항

• docker-compose.yml 파일에 마이그레이션 한 API의 포워딩을 변경해줬나요?
• Spring Secret 값을 수정하거나 추가했다면 Github Secret에서 수정을 해줬나요?
• Nestjs Secret 값을 수정하거나 추가했다면 Docker-Compose.yml 파일 및 인스턴스 내부의 .env 파일을 수정했나요?

[height]

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

[hoonyworld]

고생하셨습니다 민규님!
공동 모임장 기능을 잘 구현하신 것 같습니다!

다만, MeetingV2ServiceImpl에서 다양한 도메인의 레포지토리가 의존하고 있는데, 예외처리가 적절히 구현되지 않는다면 위험한 접근 방법이라고 생각이 듭니다.

직접 레포지토리를 의존하는 것 보다는, 서비스 레이어의 메서드 내에서 예외처리를 구현해서 해당 도메인의 서비스 레이어를 의존하도록 하는게 그 방법이 될 수 있을 것 같습니다.
고생하셨습니다!

[mikekks]

고생하셨습니다 민규님! 공동 모임장 기능을 잘 구현하신 것 같습니다!

다만, MeetingV2ServiceImpl에서 다양한 도메인의 레포지토리가 의존하고 있는데, 예외처리가 적절이 구현되지 않는다면 위험한 접근 방법이라고 생각이 듭니다.

직접 레포지토리를 의존하는 것 보다는, 서비스 레이어의 메서드 내에서 예외처리를 구현해서 해당 도메인의 서비스 레이어를 의존하도록 하는게 그 방법이 될 수 있을 것 같습니다. 고생하셨습니다!

리뷰 감사합니다!!
꼼꼼하게 리뷰 해주신 것 같아서 감사드립니다 ㅎㅎ

해당 리뷰 중 "MeetingV2ServiceImpl에서 다양한 도메인의 레포지토리가 의존하고 있는데, 예외처리가 적절이 구현되지 않는다면 위험한 접근 방법이라고 생각이 듭니다." 내용에 대해 얘기해보고 싶습니다!

1. 말씀 중에 "예외처리가 적절이 구현되지 않는다면 위험한 접근 방법" 라는 얘기를 좀 더 풀어서 말씀해주실 수 있을까요??

2. 저는 서비스가 다른 서비스를 의존하기 보다는 레이어를 하나 더 만드는 것을 제안하고 싶습니다! 서비스가 다른 서비스를 의존하게 되면 순환참조를 하기 쉬운 환경이라고 생각합니다! 그래서 서비스 레이어와 레포지토리 레이어 중간에 기본적인 CRUD 기능을 하는 레이어가 있으면 좋을 것 같습니다! 예를 들어, facade-service 또는 Usecase-service 관계라고 할까요?
   하지만 이런 구조의 경우 트레이드 오프로 코드의 복잡성이 매우 늘어난다고 생각합니다! 그래서 제가 1번에서 어떤 이유로 위험하다고 생각하시는지 궁금합니다!

[hoonyworld]

• 말씀 중에 "예외처리가 적절이 구현되지 않는다면 위험한 접근 방법" 라는 얘기를 좀 더 풀어서 말씀해주실 수 있을까요??
• 저는 서비스가 다른 서비스를 의존하기 보다는 레이어를 하나 더 만드는 것을 제안하고 싶습니다! 서비스가 다른 서비스를 의존하게 되면 순환참조를 하기 쉬운 환경이라고 생각합니다! 그래서 서비스 레이어와 레포지토리 레이어 중간에 기본적인 CRUD 기능을 하는 레이어가 있으면 좋을 것 같습니다! 예를 들어, facade-service 또는 Usecase-service 관계라고 할까요?
  하지만 이런 구조의 경우 트레이드 오프로 코드의 복잡성이 매우 늘어난다고 생각합니다! 그래서 제가 1번에서 어떤 이유로 위험하다고 생각하시는지 궁금합니다!

1번

위험하다고 말한 상황을 풀어서 설명하자면, 예외 처리가 누락될 경우 다른 도메인 및 상위 계층에까지 영향을 미칠 수 있다는 의미였습니다!

예를 들어, 특정 도메인의 서비스 레이어에서 레포지토리를 접근할 때 예외 처리가 구현되어 있다면, 해당 서비스 레이어를 통해 호출할 경우에는 예외 처리를 따로 신경 쓰지 않아도 됩니다. 하지만 레포지토리를 직접 호출하는 경우에는 이러한 예외 처리가 누락될 수 있습니다.

이로 인해 예외 발생 시 상위 계층에서 예외 상황에 적절하게 대응하지 못하게 되어, 전체적인 비즈니스 로직의 안정성을 해칠 위험이 있을 것 같다고 생각이 듭니다

2번

맞습니다 서비스 순환참조가 발생할 수 있습니다. 그래서 저도 서비스 facade나 유즈케이스를 도입하면 좋을 것 같다고 생각이 드는데요!!
트레이드 오프에 대해서의 제 의견은 메이커스의 집단 특성상 장기적인 안정성, 유지보수성, 확장성 측면에서 얻는 이점이 크기 때문에, 코드 복잡성이 증가하는 단점을 상쇄한다고 생각합니다.