[FIX] 메뉴 단순 조회 관련 API 수정

[david-parkk]

✏️ 작업 개요

• [KAN-54] 식당 주소 구 단위 분리 로직 추가 #110

⛳ 작업 분류

• AddressParser 추가
• GET/api/menus 응답 필드 변경
• GET/api/menu-folders/{menuFolderId}/menus 응답 필드 변경

🔨 작업 상세 내용

1. 일부 엔드포인트에 대해 전체 주소가 아닌 시+구 주소만을 반환하도록 API를 수정하였습니다 ex) "서울시 광진구"

💡 생각해볼 문제

• 생각해볼 내용을 적습니다

[github-actions]

Test Results

41 tests   41 ✅  1m 14s ⏱️
10 suites   0 💤
10 files     0 ❌

Results for commit 30312db.

[You-Hyuk]

혹시 Util 클래스를 만드는 것에 기준이 있는지 궁금합니다! 이전의 UrlConverter의 경우 여러 곳에서 사용하기 때문에 Util 클래스로 사용하는 것이 괜찮다고 생각했는데, AddressParser 혹은 이전의 MenuPinConverter의 경우 사용하는 곳이 적은 것 같아서 Service의 메소드로 추가하는 것은 어떤지 여쭤봅니다.

[david-parkk]

혹시 Util 클래스를 만드는 것에 기준이 있는지 궁금합니다! 이전의 UrlConverter의 경우 여러 곳에서 사용하기 때문에 Util 클래스로 사용하는 것이 괜찮다고 생각했는데, AddressParser 혹은 이전의 MenuPinConverter의 경우 사용하는 곳이 적은 것 같아서 Service의 메소드로 추가하는 것은 어떤지 여쭤봅니다.

Util과 Service의 차이는 해당 로직을 핵심 비즈니스로 바라봐야 하는지에 따라 달라지고, UrlConverter와 AddressParser는 응답 DTO를 변환하는 역활만을 담당하기 때문에 Util으로 관리되어야한다고 생각하였습니다

코멘트 주신것과 같이 Util의 구분하는 기준을 정한다면

• Util클래스로 관리되도 무방한 의존성을 가지고 경우
• 상태를 가지지 않는 경우

로 정하는 것은 어떨까요?

[david-parkk]

혹시 Util 클래스를 만드는 것에 기준이 있는지 궁금합니다! 이전의 UrlConverter의 경우 여러 곳에서 사용하기 때문에 Util 클래스로 사용하는 것이 괜찮다고 생각했는데, AddressParser 혹은 이전의 MenuPinConverter의 경우 사용하는 곳이 적은 것 같아서 Service의 메소드로 추가하는 것은 어떤지 여쭤봅니다.

MenuPinConverter를 호출하는 클래스가 적다는 이유만으로는 서비스로 관리되어야한다는 것 이외에 다른 이유가 더 필요하다고 생각합니다!

[You-Hyuk]

Util과 Service의 차이는 해당 로직을 핵심 비즈니스로 바라봐야 하는지에 따라 달라지고, UrlConverter와 AddressParser는 응답 DTO를 변환하는 역활만을 담당하기 때문에 Util으로 관리되어야한다고 생각하였습니다

코멘트 주신것과 같이 Util의 구분하는 기준을 정한다면

• Util클래스로 관리되도 무방한 의존성을 가지고 경우
• 상태를 가지지 않는 경우

로 정하는 것은 어떨까요?

핵심 비즈니스 로직인지에 대한 관점으로 분리하는 방식은 좋은 것 같습니다! 말씀해주신 기준으로 Util을 사용하면 될 것 같습니다.

[You-Hyuk]

MenuPinConverter를 호출하는 클래스가 적다는 이유만으로는 서비스로 관리되어야한다는 것 이외에 다른 이유가 더 필요하다고 생각합니다!

사용 빈도가 적어 Class 단위까지의 관리가 필요한지에 대해서 모호함을 가졌었는데, 달아주신 코멘트의 관점에서는 분리하는 것이 옳은 것 같습니다!