본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 19일차!
오늘은 커뮤니티 피드 서비스의 피드 조회 api를 구현하는 작업을 진행하였다.
피드 조회 기능을 구현하기 위해, 특정 사용자가 어떤 게시글을 피드로 받아야 하는지를 저장해두는 엔티티를 만들었다.
@Entity
@Table(name = "community_user_post_queue")
public class UserPostQueueEntity {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private Long userId; // 피드를 받아볼 사용자 (팔로워)
private Long postId; // 게시글 ID
private Long authorId; // 게시글 작성자
}
기존 엔티티만을 활용해서 쿼리만으로 피드 조회를 해결하려고 했다면 엄청나게 복잡한 join이 필요했을 것이다.
어떠한 기능을 구현할 때, 기능이 필요로 하는 것이 무엇인지 잘 파악하고 그에 맞는 구조를 설계할 수 있는 능력이 정말 중요한 것 같다는 생각이 든다...
강사님께서 이런 질문을 하셨다. post > application > dto에 피드의 content를 반환하는 dto를 추가해도 될 것 같은데, post > ui > dto 하위에 위치하도록 하였다. 이렇게 구조를 짠 이유는 무엇일까?
프로젝트 구조를 보면 application의 dto 디렉토리 하위에 위치한 dto는 모두 request dto이고, ui의 dto 디렉토리 하위에는 response dto가 위치해있다. 또한, application 디렉토리에는 service 클래스들이 있고, ui 디렉토리에는 controller 클래스들이 있는 것으로 보아, 내가 생각하기에는 레이어의 역할을 명확하게 분리하기 위해서 구조를 나눈 것 같다. application에서는 비즈니스의 흐름을 제어하는 역할을, ui에서는 외부 요청을 받고 응답을 반환하는 역할을 하기에 response 객체는 application에서 필요하지 않은 것이다.
더 궁금해져서 관련 내용을 찾아보았더니, '의존 방향' 이라는 개념을 알게 되었다.
보통 계층 구조의 흐름은 [UI Layer] → [Application Layer] → [Domain Layer] → [Persistence Layer] 순으로 흐른다.
만약 response dto가 application 레이어에 위치한다면, 의존 방향이 거꾸로 흐르게 되면서 레이어들이 서로 영향을 받게 되고, 코드의 유지보수성과 재사용성이 낮아지게 되는 문제가 생긴다.