Spring에서 레이어드 아키텍처 관련 코드 패턴 질문

Question

안녕하세요

개발을 진행하는 도중 코드 디자인 관련해서 궁금한 점이 생겨, 여러 선배님들께 질문을 드려봅니다

검색 목록 조회 시, 많은 parameter 처리 방법

특정 검색화면을 표시하기 위해 필요한 값들인 등록일 검색 날짜, 검색어와 같은 부문을 Controller 에서 modelattribue 로 받았는데 필드 수가 10개 이상 됩니다.

문제는 해당 field 들을 서비스 > 레포지토리 까지 옮겨야 하는데 modelattribute 객체를 사용하자니 view 에 종속 된 객체를 옮기는 게 맞을까 라는 의문이 들고, 각 field 를 모두 꺼내자니 메서드 마다 10개씩 파라미터 받는게 또 아닌 것 같다는 생각이 들었습니다.

이러한 상황들은 어떤식으로 처리하시는 지 궁금합니다.

JPA 를 사용 중인데, open in view 속성을 막아놔서 service 레이어에서 entity를 dto로 변환하는 작업을 진행합니다. 이때 궁금한 점은 해당 method 에서 반환 시 다른 entity의 field값 하나가 필요한 경우가 간혹 있다는 것 입니다.

해당 dto 에 field 를 추가하자니 해당 값이 필요없는 경우에도 다른 entity를 조회하여 db select 나가는게 싫고 객체를 하나 더 만들자니, 다른 상황에서도 비슷한 경우가 많아 객체가 너무 많아질 것 같아 고민입니다.

계속 해서 좋은 방법을 고민하고 찾아봤지만, 결론이 나질 않아 선배님들께 질문 드려 봅니다.

장준영 · Accepted Answer

안녕하세요! 글 전반적인 내용을 보니 클린 코드에서 힌트를 얻을 수 있는 점들에 대해 고민하고 계신 것 같아요.

때문에 제 답변 외에도 클린 코드 내용이나 구체적인 상황을 명시한 영문 검색을 통해 더 큰 커뮤니티에서 답을 얻으시는 것도 좋을 것 같습니다:)

자, 이제 제 주관으로 말씀드릴게요.

첫번째 질문은 인자로 넘겨야할 값의 개수가 많을 때 어떻게 하는 것이 좋은가? 인 것 같은데요!
객체를 생성해서 옮기시는 편이 좋습니다.
특히 10개가 넘어가는 경우라면 더더욱 그렇구요.
몇 개를 기준으로 하느냐는 컨벤션의 차이일 것 같아요.
그러나 repository 레이어까지 내려가기 위해 각 레이어 별로 어떤 객체로 옮기면 좋을 지는 VO, DTO 등의 개념을 확인해보면서 적용해보면 될 것 같아요:)

두번째 질문은 해석하기 조금 애매했는데, JPA 속성의 경우엔 왜 그렇게 설정했는지 고민해봐서, 반대로 적용해도 상관 없다면 그렇게 하는 게 좋을 것 같아요.

그리고 결국엔 다른 entity 의 데이터가 필요하다는 것이 문제 상황일텐데, 이 또한 JPA에서 도와주는 연관관계 등 여러 방법을 고민해보는 것이 가장 원초적일 것 같으나 이런 고민까지 이미 마친 단계에서 DTO를 따로 또 만드는 게 과연 좋은것이냐? 라는 질문까지 내려온거라면 저는 그렇다에 한 표 던지겠습니다.

OOP의 여러 원칙들을 알고 계시다면 그 안에서 가장 공통적으로 쓰이는 개념을 떠올려보세요!
아마도 단일 책임 일 것입니다.
이름은 여러 원칙으로 나눠져도, 결국 기반이 되는 규칙은 이거니까요.

DTO라고 하면 외부와 통신하기 위한 데이터 객체일텐데 당연히 통신별로 다양하고 또 많을 수 밖에 없습니다.

만약 정말 너-무 많다면 애초에 설계가 잘못 되었거나 혹은 통신하는 대상이 되는 서버 or 클라이언트와 협의가 잘못 되었을 수도 있어요.

제가 직접 모든 인프라와 코드를 살펴본 게 아니라 여러 추측으로 제안하는 것들이긴 하지만 여기서의 키워드들로 한번 더 검색해보시면 좋은 혜안을 얻으실 수 있을 것이라 생각합니다:)