[StudyHub] 조회 메서드 반환 객체 분리

서론

---

프로젝트의 repository 레이어 단위테스트를 작성하던 중 개선사안 두가지를 발견했다.

 

 

[개선 사안 1]

게시글 조회 관련 StudyPostRepositoryImpl 객체의 메서드들은 동적 쿼리 생성 시 아래 코드와 같이 반환값으로 각기 다른 dto를 반환하고 있었다.

@Override
public Slice<FindPostResponseByInquiry> findByInquiry(final InquiryRequest inquiryRequest, final Pageable pageable, Long userId) {
    QStudyPostEntity post = studyPostEntity;
    QUserEntity user = userEntity;
    QBookmarkEntity bookmark = bookmarkEntity;
        ...중략

 

@Override
public Slice<GetBookmarkedPostsData> findPostsByBookmarked(Long userId, Pageable pageable) {
    QStudyPostEntity post = studyPostEntity;
    QBookmarkEntity bookmark = bookmarkEntity;
        ...중략

 

 

FindPostResponseByInquiry, GetBookmarkedPostsData와 같은 반환 객체들을 하나의 객체로 통합하면 코드 유지보수가 용이해질 것이라 생각했지만 결과적으로 그렇지 않았기 때문에 왜 통합하면 안되는지 설명해보겠다.

 

 

 

본론

---

 

프로젝트의 Dto 흐름은 사진과 같다. 부연설명 하자면 Persistence Layer(Repository)에서 반환한 Dto를 Business Layer에서 변환해 Presentation Layer로 전달하는 것 이다.

 

Persistence Layer에서 사용하는 Dto를 그대로 Presentation Layer로 가져가게 되면 계층구조에 위반되고 이는 추후 유지보수 시 불편함을 겪게할 수 있기 때문에 레이어간 Dto를 따로 생성했다.

 

Persistence Layer에서 Business Layer로 보내는 Dto를 통합하기 위해서는 현재 반환하고 있는 모든 Dto 객체의 값들을 가지는 Dto 객체가 필요하다.

 

아래는 현재 통합하려는 Dto 객체들이다.

 

public FindPostResponseByInquiry(Long postId, MajorType major, String title, LocalDate studyStartDate, LocalDate studyEndDate, LocalDateTime createdDate, Integer studyPerson, GenderType filteredGender, Integer penalty, String penaltyWay, Integer remainingSeat, boolean close, boolean isBookmarked, UserData userData) {
    this.postId = postId;
    this.major = major;
    this.title = title;
    this.studyStartDate = studyStartDate;
    this.studyEndDate = studyEndDate;
    this.createdDate = createdDate;
    this.studyPerson = studyPerson;
    this.filteredGender = filteredGender;
    this.penalty = penalty;
    this.penaltyWay = penaltyWay;
    this.remainingSeat = remainingSeat;
    this.close = close;
    this.isBookmarked = isBookmarked;
    this.userData = userData;
}

public GetBookmarkedPostsData(Long postId, MajorType major, String title, String content, int remainingSeat, boolean close) {
    this.postId = postId;
    this.major = major;
    this.title = title;
    this.content = content;
    this.remainingSeat = remainingSeat;
    this.close = close;
}

public RelatedPostData(Long postId, String title, MajorType major, int remainingSeat, UserData postedUser) {
    this.postId = postId;
    this.title = title;
    this.major = major;
    this.remainingSeat = remainingSeat;
    this.postedUser = postedUser;
}

이 세가지 Dto 객체의 필드를 모두 통합하면 아래와 같은 Dto 객체가 만들어진다.

 

@Getter
public class IntegratedPostData {

    private Long postId;
    private MajorType major;
    private String title;
    private LocalDate studyStartDate;
    private LocalDate studyEndDate;
    private LocalDateTime createdDate;
    private Integer studyPerson;
    private GenderType filteredGender;
    private Integer penalty;
    private String penaltyWay;
    private Integer remainingSeat;
    private boolean close;
    private boolean isBookmarked;
    private UserData userData;
    private String content;
    private Long postedUserId;
    private String chatUrl;
    private StudyWayType studyWay;
    private Long userId;
}

이후 아래와 같이 반환 객체를 통합해줬다.

 

이 때 Slice를 반환하는 방식에서 List를 반환하게 했는데 이유는 다음과 같다.

 

Repository 레이어에서 DB와 통신해 데이터베이스 내 정보들을 가져오면서 List -> Slice 변환까지 담당하는 것은 책임이 많아진다고 생각해 이 부분을 Service 레이어에서 처리하도록 변경했다.

 

public List<IntegratedPostData> findByInquiry(final InquiryRequest inquiryRequest, final Pageable pageable, Long userId) 
public List<IntegratedPostData> findPostsByBookmarked(final Long userId, final Pageable pageable)
public List<IntegratedPostData> findByMajor(final MajorType major, final Long exceptPostId)

전체적인 흐름은 아래와 같다.

1. Repository 레이어에서 IntegratedDto 반환 
2. Service 레이어에서 IntegratedDto를 반환 Dto 형태로 변경 
3. 반환 Dto 객체들을 Slice로 담아 Controller 레이어에 전달

 

 

문제 발생

---

 

하지만 현업에서 종사하고 계신 멘토님의 피드백, 팀원과의 소통을 통해 몇가지 단점을 발견했다.

 

 

1. 공통 Dto를 여러개의 메서드가 공유하고 있으면 불필요한 필드가 너무 많아져서 유지보수에 어려움이 커진다.

 

예를 들어 아래 사진과 같이 게시글의 전체 정보를 조회하지 않고 부분 정보만 조회하는 경우 공통 Dto 객체는 Null이 들어간 필드를 가진채 생성된다. 이는 추후 NPE 발생 가능성이 있을 수 있다.

 

 

2. 타 개발자가 이 코드를 읽고 의도를 파악하기 어렵게된다.

 

3. 작은 객체를 생성해 책임을 나누면 하지 않아도 되는 작업을 큰 객체가 너무 많은 필드를 관리하는 책임을 가지게 됨으로써 생산성에 저하가 되는 비용이 들어가게 된다.

 ex) 사용하고자 하는 필드가 Null이면 NPE가 발생하기 때문에 Optional을 이용해 확인하는 작업이 추가적으로 필요하게된다.

 

 

 

해결

---

변경에 유연한 객체지향적인 설계는 전체 스프링 어플리케이션에서 핵심이 되는 Business 단에서 유지가 돼야하고 양 끝단인 Controller와 Repository는 변경이 무조건 일어날 수 밖에 없고 변경이 많이 일어나는 곳이다. 

 

예를들면 DBMS가 MySQL에서 다른 DB로 이관된다던가, 혹은 Persistence Layer 자체를 JPA에서 MyBatis로 변경하는 경우가 있다. 그만큼 Persistence 레이어는 변경이 잦기 때문에 해당 계층의 코드가 아닌 Business Layer에서 객체지향 적인 설계나 변경에 유연한 코드를 작성해야한다.

 

하지만 지금은 Repository의 유지보수를 위해 공통 Dto를 만들어서 Service 코드를 변경하고 있기 때문에 주객이 전도가 된 상황이다.

 

이러한 단점들이 있기 때문에 이전에 계획했던 설계로 돌아가 각 메서드마다 Dto를 따로 생성하기로 결정했다.

 

 

 

https://github.com/study-hub-inu/study-hub-server