[Spring] Business Layer와 Presentation Layer 분리의 중요성

 💡결론

Request/Response DTO는 API 입출력 형식에 가깝고, API 요구사항은 FE 화면 구성이나 기획 변경에 따라 자주 바뀐다. 그래서 Service가 DTO를 직접 반환하면 비즈니스 로직이 프레젠테이션 계층의 변화에 끌려다닐 수 있다. 이번 프로젝트에서는 Service는 Entity, VO, primitive, Map 같은 비즈니스에 가까운 값을 반환하고, Controller에서 Response DTO로 변환하는 방식을 사용했다.

1. 문제 발생 상황

이번 SOPT에서 합동 세미나를 진행했고 아래와 같은 일이 있었다.

내가 원래 배웠던 구조는 차트 API, 좋아요 토글 API, 아티스트 곡 목록 API를 구현하면서 Service가 바로 Response DTO를 반환할 수 있었다. 

하지만 리드님께서는 Business Layer와 Presentation Layer 를 확실히 원했고 합동 세미나 그라운드 룰에 규칙을 적으셨다.

합동 세미나 그라운드 룰을 만들면서 ”귀찮게 왜 분리시키는거지? 한 번에 해결하면 쉽고 파일양도 줄일 수 있어서 이득 아닌가..?” 라는 생각에 사로 잡혀있었다.

하지만 이렇게 하면 Service가 API 응답 형태를 알게 되어버리는 문제가 있었다.

 

2. 합동 세미나 그라운드 룰

• 비즈니스 로직: 서버가 책임지는 규칙
  • 예: 유저 검증, 권한 확인, 좋아요 여부 판단, 좋아요 수 증가/감소, 정렬 기준에 따른 곡 조회
• 프레젠테이션 로직: API 응답을 어떻게 보여줄지 조립하는 영역
  • 예: FE가 필요한 형태로 songId, title, artist, albumImageUrl을 묶어서 내려주기
    • 즉, 우리는 프론트엔드가 뭘 하지 않고 딱 보여주는 형태로 보내주쟈!

⇒ Service는 최대한 얇게, Controller에서는 조립 시키기!

3. 합동세미나 예시

문제 발생 상황

public record ChartSongInfo(
				 Long songId,
        String title,
        Long artistId,
        String artistName,
        String albumImageUrl
) {

}

• 맨 처음에는 Vo객체는 관심사를 모으는 걸로 이해해서 곡과 아티스트를 한꺼번에 모으면 되겠네 하고 Vo패키지에 적용시켰다

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class ChartService {

    private final SongDetailRepository songDetailRepository;

    public ChartResponse findChartByFilter(final ChartFilterType chartFilterType) {
        List<ChartSongInfo> chartSongs = switch (chartFilterType) {
            case TOP100 -> songDetailRepository.findTop100Chart();
            case HOT100 -> songDetailRepository.findHot100Chart();
            case ABROAD_2006, SWEET -> songDetailRepository.readChart();
        };

        return ChartResponse.of(chartSongs);
    }
}

• 그 후 Service에서는 dto/reponse/에 있는 ChartResponse를 바로 반환하는 실수를 했었다
  • 그라운드 룰에 의해 Service에서는 dto를 반환하면 안됨

해결 방법

1. vo 객체가 필요없다고 판단이 들어서 삭제 시켰다
   • ChartResponse에서 아래와 같이 반환하게 되면 join도 필요없이 반환할 수 있다는 장점에서 삭제

   public record ChartResponse(
           @Schema(description = "차트 곡 목록")
           List<SongInfo> songs
   ) {
   
       public static ChartResponse of(List<Song> songs, Map<Long, List<Artist>> artistsMap) {
           return new ChartResponse(
                   songs.stream()
                           .map(song -> SongInfo.of(
                                   song,
                                   artistsMap.getOrDefault(song.getId(), List.of())
                           ))
                           .toList()
           );
       }
   
       public record SongInfo(
               @Schema(description = "곡 ID", example = "1")
               Long songId,
   
               String albumImageUrl
   
       ) {
   
           public static SongInfo of(Song song, List<Artist> artists) {
               Artist artist = artists.getFirst();
   
               return new SongInfo(
                       song.getId(),
                       song.getTitle(),
                       new ArtistInfo(artist),
                       song.getAlbum().getImageUrl()
               );
           }
       }
   
       public record ArtistInfo(
               String name
       ) {
   
           public ArtistInfo(Artist artist) {
               this(artist.getId(), artist.getName());
           }
       }
   }

2. Service는 Entity, VO, primitive, Map 같은 비즈니스에 가까운 값을 반환하기
   • Mapper를 사용한 아티스트 곡 목록 조회 Service

package org.sopt.collaboration.melon.domain.song.service;

import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;
import lombok.RequiredArgsConstructor;
import org.sopt.collaboration.melon.domain.artist.entity.Artist;
import org.sopt.collaboration.melon.domain.song.entity.Song;
import org.sopt.collaboration.melon.domain.song.entity.SongArtist;
import org.sopt.collaboration.melon.domain.song.repository.SongArtistRepository;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class SongArtistService {

    private final SongArtistRepository songArtistRepository;

    public List<Artist> findAllArtistsBySongId(Long songId) {
        return songArtistRepository.findAllBySongId(songId)
                .stream()
                .map(SongArtist::getArtist)
                .toList();
    }

    public Map<Long, List<Artist>> findArtistAsMap(List<Song> songs) {
        List<Long> songIds = songs.stream()
                .map(Song::getId)
                .toList();

        return songArtistRepository.findAllBySongIdIn(songIds).stream()
                .collect(Collectors.groupingBy(
                        SongArtist::getSongId,
                        Collectors.mapping(SongArtist::getArtist, Collectors.toList())
                ));
    }

    public List<Song> findArtistSongBySort(Long artistId, List<Song> sortedSong) {
        List<Long> artistSongIds = songArtistRepository.findSongIdsByArtistId(artistId);
        return sortedSong.stream()
                .filter(song -> artistSongIds.contains(song.getId()))
                .toList();
    }

}

 

3. Controller는 조립해서 Dto로

@RestController
@RequestMapping("/v1/chart")
@RequiredArgsConstructor
public class ChartController implements ChartApi {

    private final ChartService chartService;
    private final SongArtistService songArtistService;

    @GetMapping
    public CommonResponse<ChartResponse> getChartByFilter(
            @RequestParam(defaultValue = "TOP100") String chartFilter
    ) {

        List<Song> chartSongsByFilter = chartService.findChartSongByFilter(ChartFilterType.from(chartFilter));

        Map<Long, List<Artist>> artistsMap = songArtistService.findArtistAsMap(chartSongsByFilter);

        ChartResponse response = ChartResponse.of(chartSongsByFilter, artistsMap);

        return CommonResponse.success(ChartSuccessCode.GET_CHART, response);
    }

}

---

정리

개념을 알기 전에는 Business Layer와 Presentation Layer 분리하는 게 너무 귀찮고 실수도 많았었다.

하지만 합동 세미나를 진행하면서 많은 API이 삭제되거나 추가되거나 수정되는 일이 많이 발생하였다. 이 때마다 Service에서 dto를 반환하지 않아서 간편하게 Controller와 dto만 신경 쓰면 되었다.

가장 크게 느낀 부분은 차트 API였다. 필터 정렬 순서를 어떻게 처리할지 팀 내에서 여러 번 논의가 오갔고, 요구사항도 계속 바뀌었는데, 정렬과 계산 로직을 Service 쪽에서 집중적으로 관리할 수 있어서 수정 부담이 줄었다.

또한 차트 API와 아티스트 곡 목록 조회 API에서 계산 로직이 겹치는 필터가 있었는데, 공통 로직을 재사용하고 필터명만 다르게 처리할 수 있도록 구현하면서 코드량도 줄일 수 있었다.

 

 

 

참고자료

Command 읽어봤던 자료

https://lets-do-the-odessey.tistory.com/47