Feat #38 매칭 필터링 및 알고리즘 구현 #38

huncozyboy · 2025-01-16T14:36:33Z

📌 관련 이슈

🚀 작업 내용

사용자가 입력한 출발지, 도착지, 태그 조건에 맞는 활성 상태의 매칭 방을 검색하는 로직(findRoom 메서드)
*거리 조건은 300m 이내로 설정했고, 태그가 비어있는 경우에도 처리할 수 있도록 설정하였습니다

멤버 아이디로 사용자 조회 및, 해당 특정 사용자가 방에 이미 방에 존재하는지 조회
ST_Distance_Sphere를 활용하여 출발지(300m 이내) 도착지(300m 이내)의 매칭 방을 필터링
검색된 매칭 방 리스트에서 ACTIVE 상태인 방만 검색되도록 필터링
태그 조건(criteria)이 주어진 경우, 태그 조건을 만족하는 방만 추가로 필터링
위 조건에 맞는 방이 있으면 해당 방에 참가할 수 있도록 방의 정보를 조회
조건에 맞는 방이 없다면 해당 방을 생성

전체 매칭방을 리스트로 조회(페이지네이션 방식)

페이지 번호랑 페이지 사이즈를 입력받아 조회
페이지 번호가 유효하지 않은 경우 예외처리
매칭 방의 정렬 기준은 id를 기준으로 내림차순으로 정렬
pageable로 매칭방의 리스트를 반환

📸 스크린샷

SSE 구독 후 포스트맨에서 테스트 진행했습니다

DB에 매칭방 생성까지 확인했습니다

추가로 동일한 유저가 똑같은 조건의 방을 생성하려고 할시, 이미 존재하는 매칭방이라는 예외를 던져주도록 설계했습니다

📢 리뷰 요구사항

주영님과 충돌을 방지하고자 매칭시 필터링 로직이랑 전체 매칭방 리스트 조회 먼저 해당 PR에서 작업해서 머지하도록 하고,
블랙리스트와 친구추가는 별도의 이슈를 생성해서 추후에 작업하도록 협의했습니다

현재 저희가 출발지(가천대학교 정문, 1번출구) 와 도착지(가천대학교 기숙사, AI 공학관)로 정해져있는 설계였기에
Haversine이랑 Radian을 통한 위도 경도 계산법은 사용하지 않았습니다
하지만 추후에 앱으로 마이그레이션 후 출발지와 도착지를 지도에서 동적으로 선택할 수 있도록 확장되는 경우에는 리팩토링이 필요해보입니다

soyesenna

고생하셨어요!!

soyesenna · 2025-01-16T15:59:33Z

src/main/java/com/gachtaxi/domain/matching/algorithm/service/MockMatchingAlgorithmService.java

+    Members user = memberRepository.findById(userId)
+            .orElseThrow(MemberNotFoundException::new);


MemberService에 findById 메서드가 있습니다!!
해당 메서드를 사용하는게 좋아보여요

MemberService에 예외처리까지 되어있는 메서드를 사용하면,
불필요한 메서드 추가랑 예외처리를 안해줘도 될거같네요. 수정 완료했습니다 !

hyxklee

고생하셨습니다!
mysql에서 거리로 검색하는 기능이 있다는 것은 처음 알았네요!
현재 방식이라면 차후 사용자의 현재 위치를 입력받을 때도 확장성 있게 사용이 가능할 것 같습니다!

hyxklee · 2025-01-17T00:49:32Z

src/main/java/com/gachtaxi/domain/matching/algorithm/service/MockMatchingAlgorithmService.java

+     */
+    Members user = memberService.findById(userId);
+
+    if (matchingRoomRepository.existsByMemberInMatchingRoom(user)) {


예외를 던져주게 되면 매칭 이벤트가 종료 되나요??

매칭 이벤트가 종료되거나 기존 매칭방이 삭제되는 것은 아니라고 생각해주시면 됩니다. 기존의 매칭방은 정상적으로 유지되고,
만약에 사용자가 이미 생성된 매칭방에 대해 매칭 종료를 요청하거나 취소를 원할 경우는 매칭 취소와 관련된, 별도의 권한이라 매칭 취소의 프로세스에 맞다고 생각했습니다

해당 부분에 대해서는 고민을 많이 했던 부분인데 400을 던져주는 방식으로 설계한 이유는,
사용자가 이전에 설정한 조건과 동일한 조건으로 매칭방을 생성하려고 시도하는 상황에서는 이미 해당 조건에 맞는 매칭방이 존재하는 전제가 있는거니까 정상적인 흐름이 아니라고 간주하고, 이를 막아주는 것이 올바른 흐름이라고 판단하였습니다

그래서 동일한 조건으로 생성된 방이 이미 존재하는 상황에서는 중복된 방 생성을 방지하기 위해
서버단에서 예외를 던져주도록 설계하였습니다. 원래는 클라이언트 측에서
이미 참여 중인 매칭방 화면으로 유저를 리다이렉트하는 것이 더 적절하다고 생각했지만,
안정성을 고려했을 때 서버단에서도 중복 여부를 검증하는 것이 필요하다고 생각했습니다

hyxklee · 2025-01-17T00:52:02Z

src/main/java/com/gachtaxi/domain/matching/algorithm/service/MockMatchingAlgorithmService.java

-              .roomId(matchingRoom.getId())
-              .maxCapacity(matchingRoom.getCapacity())
-              .build());
+              FindRoomResult.builder()


room을 전달해줘서 객체 내부에서 생성하도록 캡슐화를 시키면 통일성 측면에서 좋을 것 같아요!

해당 빌더 부분도 객체 내부에서 생성하도록 해서 반영하여 수정하였습니당

hyxklee · 2025-01-17T00:55:35Z

src/main/java/com/gachtaxi/domain/matching/algorithm/service/MockMatchingAlgorithmService.java

+    /*
+      ACTIVE 상태인 방만 필터링
+     */
+    matchingRooms = matchingRooms.stream()


DB에서 가져올 때 Active인 방들만 가져오는 것은 어떨까요??
Jpa 메서드로도 작성이 가능하니 조회할 때 필터링을 거쳐주는 것도 성능에 좋아보여요

넵 원래는 Active 상태의 방과 태그 조건까지 모두 쿼리로 조회해 오도록 설계했었는데, 주영님의 의견을 반영하여 수정했습니다

해당 조건들을 모두 쿼리에서 처리하려면 쿼리가 너무 복잡하고 길어져서 서버단 성능에 부담이 갈 수도 있고, 가독성이 떨어질 수도 있다는 피드백이 있었어서, 해당 부분 고려한 뒤에 Active 상태와 태그 필터링은 서비스 단에서 처리하는 방식으로 이전하였습니다...!

아항 알겠습니당

hyxklee · 2025-01-17T00:58:08Z

src/main/java/com/gachtaxi/domain/matching/algorithm/service/MockMatchingAlgorithmService.java

-    List<MatchingRoom> matchingRoomList = this.matchingRoomRepository.findAll();
-    if (!matchingRoomList.isEmpty()) {
-      MatchingRoom matchingRoom = matchingRoomList.get(0);
+  public Optional<FindRoomResult> findRoom(Long userId, double startLongitude, double startLatitude, double destinationLongitude, double destinationLatitude,


현재는 서버에 저장된 Rount(가천대 - 정문) 노선만 제공을 하고 있으니, 서버에서 제공하는 정보를 토대로 클라이언트에서 위도 경도 값을 그대로 넣어줘야할 것 같아요!

그렇다면 입력받은 값에 대한 유효성 검증이 추가되면 좋을 것 같아요. 위도, 경도 값으로 Route가 존재하는지 조회를 해본다거나 하는

만약 클라이언트에서 보내주는 위도, 경도의 정보로 Route를 조회할 수 없다면,
잘못된 위도경도 입력 자체에 대한 내용은 컨트롤러 단에서 validation으로 1차적으로 걸러져서 필터링 됩니다
그렇다면 2차적으로 올바른 위도 경도가 입력 되었을때, 라우트가 조회되지않아서 방이 검색되지 않는 경우는 정상적인 플로우라고 생각했어서 해당 부분에 대한 유효성 검증은 필요없다는 생각했었습니당
추후 리팩토링시 만약 해당 부분에 대해서 Haversine이랑 Radian을 사용해서 위도 경도 자체를 세밀하게 계산을 해준다고 하면 필요한 예외처리를 추가하는 방식으로 해도 좋을거같습니다 !

hyxklee · 2025-01-17T00:58:32Z

src/main/java/com/gachtaxi/domain/matching/common/exception/PageNotFoundException.java

+
+public class PageNotFoundException extends BaseException {
+    public PageNotFoundException() {
+        super(HttpStatus.NOT_FOUND, ErrorMessage.NOT_FOUND_PAGE.getMessage());


정적 경로 설정이 빠진 것 같아요!

hyxklee · 2025-01-17T01:02:37Z

src/main/java/com/gachtaxi/domain/matching/common/repository/MatchingRoomRepository.java

+            "WHERE " +
+            "FUNCTION('ST_Distance_Sphere', FUNCTION('POINT', :startLongitude, :startLatitude), FUNCTION('POINT', r.route.startLongitude, r.route.startLatitude)) <= 300 " +
+            "AND FUNCTION('ST_Distance_Sphere', FUNCTION('POINT', :destinationLongitude, :destinationLatitude), FUNCTION('POINT', r.route.endLongitude, r.route.endLatitude)) <= 300 ")
+    List<MatchingRoom> findRoomsByStartAndDestination(


거리도 파라미터로 빼주고 호출하는 쪽에서 상수로 관리해주면 거리 변경이 필요할 때 유용할 것 같아욤

기존 쿼리의 <= 300 부분 :radius로 설정해줘서 아래 내용처럼 상수로 선언해서 사용하겠습니당

private static final double SEARCH_RADIUS = 300.0;

hyxklee · 2025-01-17T01:03:26Z

src/main/java/com/gachtaxi/domain/matching/common/service/MatchingRoomService.java

+    double endLongitude = Double.parseDouble(endCoordinates[0]);
+    double endLatitude = Double.parseDouble(endCoordinates[1]);
+
+    Route route = Route.builder()


해당 객체 생성의 책임도 객체 내부로 이전하면 통일성 있고 좋을 것 같아요!

해당 부분은 원래 구현되어 있던 내용을 그대로 사용했기 때문에 미처 확인하지 못했던 부분입니다
현재 구현한 설계들과 동일한 패턴들 처럼, Route 객체 내부로 이전하여 통일성을 유지하는 것이 저도 맞다고 생각되어서 반영하도록 하겠습니다 !

koreaioi

고생하셨습니다!

soyesenna

고생하셨어용!!

huncozyboy added 6 commits January 16, 2025 22:42

refactor: 자동 매칭 handlerAutoRequestMatching 메서드 위도 경도 정보 사용해주도록 설정

eef7b34

refactor: 300m 이내 반경 지정 위해 위도 경도 정보 사용하도록 설정

d796daa

feat: 매칭방 리스트 검색 쿼리 및 중복 참여 방지 쿼리 구현

103f446

refactor: saveRoute 메서드 위도와 경도 사용하도록 변경

8edc548

refactor: Route 엔티티 위도와 경도 필드 추가

43382ca

feat: 매칭 출발지와 도착지 좌표, 태그 조건으로 필터링 메서드 구현

b305484

huncozyboy added 🔨 Refactor 코드 리팩토링 ✨ Feature 기능 개발 및 요구사항 변경 반영 labels Jan 16, 2025

huncozyboy self-assigned this Jan 16, 2025

huncozyboy linked an issue Jan 16, 2025 that may be closed by this pull request

[Feat]: #30 매칭 필터링 및 알고리즘 구현 #30

Closed

3 tasks

huncozyboy added 7 commits January 17, 2025 00:20

feat: 페이지 예외처리인 PageNotFoundException 구현

579a8dd

feat: 페이지 예외 메시지 구현

f29a3ba

feat: 페이지 리스트로 조회해오는 메서드 구현

2419893

feat: 인터페이스에서 findMatchingRooms 메서드 추가

109e7d2

refactor: 이미 참여중인 유저 검증 로직 수정

18030a7

feat: 태그 조건이 비어있는 경우 findRoomsByStartAndDestination 메서드 추가

7f4004a

feat: findRoomsByStartAndDestination 메서드 서비스 단에서 구현

add4ca9

soyesenna self-requested a review January 16, 2025 15:58

soyesenna reviewed Jan 16, 2025

View reviewed changes

huncozyboy added 8 commits January 17, 2025 04:28

refactor: memberService에 있는 findById로 조회

848e35d

feat: containsTag 특정 태그를 포함하는 방인지 확인하는 메서드 구현

d7fe04d

refactor: 레포에서는 거리와 관련된 정보만 조회해오도록 쿼리문 수정

a290383

feat: 특정 태그를 포함하는지 확인하는 matchesTag 메서드 구현

dd9a668

refactor: 필터링 부분 리팩토링

dee5512

feat: 매칭방 중복 생성 예외처리 구현

53befbb

feat: 매칭방 중복 생성 예외 메시지 추가

4ce39e3

refactor: 동일한 유저가 똑같은 조건의 방 생성시 중복 예외처리

f5d9b52

huncozyboy requested review from hyxklee and koreaioi January 16, 2025 20:22

hyxklee reviewed Jan 17, 2025

View reviewed changes

huncozyboy added 4 commits January 17, 2025 12:42

refactor: 빌더패턴 MatchingRoom 엔티티 내부로 이전

289fea5

refactor: 서비스단 빌더 패턴 간단하게 수정

68ef3a1

refactor: 300m 거리 동적으로 설정되도록 파라미터로 수정

783fdd9

refactor: SEARCH_RADIUS 거리 상수 추가

c7889f6

koreaioi approved these changes Jan 17, 2025

View reviewed changes

soyesenna approved these changes Jan 18, 2025

View reviewed changes

huncozyboy merged commit 24d7f23 into dev Jan 18, 2025
2 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feat #38 매칭 필터링 및 알고리즘 구현 #38

Feat #38 매칭 필터링 및 알고리즘 구현 #38

huncozyboy commented Jan 16, 2025 •

edited

Loading

soyesenna left a comment

soyesenna Jan 16, 2025

huncozyboy Jan 16, 2025

hyxklee left a comment •

edited

Loading

hyxklee Jan 17, 2025

huncozyboy Jan 17, 2025 •

edited

Loading

hyxklee Jan 17, 2025

huncozyboy Jan 17, 2025

hyxklee Jan 17, 2025

huncozyboy Jan 17, 2025

hyxklee Jan 17, 2025

hyxklee Jan 17, 2025

huncozyboy Jan 17, 2025

hyxklee Jan 17, 2025

hyxklee Jan 17, 2025

huncozyboy Jan 17, 2025

hyxklee Jan 17, 2025

huncozyboy Jan 17, 2025

koreaioi left a comment

soyesenna left a comment

		Members user = memberRepository.findById(userId)
		.orElseThrow(MemberNotFoundException::new);

Feat #38 매칭 필터링 및 알고리즘 구현 #38

Feat #38 매칭 필터링 및 알고리즘 구현 #38

Conversation

huncozyboy commented Jan 16, 2025 • edited Loading

📌 관련 이슈

🚀 작업 내용

📸 스크린샷

📢 리뷰 요구사항

soyesenna left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hyxklee left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

huncozyboy Jan 17, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

koreaioi left a comment

Choose a reason for hiding this comment

soyesenna left a comment

Choose a reason for hiding this comment

huncozyboy commented Jan 16, 2025 •

edited

Loading

hyxklee left a comment •

edited

Loading

huncozyboy Jan 17, 2025 •

edited

Loading