TIL - #25 Service의 Repo 참조 혹은 Service 참조

Quann·2023년 1월 26일
0

00. 개요

Service 레이어에서 다양한 Repository를 참조하게 되면서,
이렇게 참조하는 것이 맞는가 싶은 의문이 들었다.

예를들어, PostService에서 PostRepository, CommentRepository, UserRepository 등을 의존하게 되고있는 상황인데
이렇게 된다면, PostService에서 다른 객체들에 관해 접근 권한이 생기게 되고 매우 쉽게 데이터 변환이 가능할 것 같다는 생각이 들은 것이다.

PostService에서 Comment 객체를 변환하거나 삭제하는 일을 하는 것은 하면 안될 것이라 생각했다.


01. 생각

@Service
@RequiredArgsConstructor
public class PostServiceImpl implements PostService {

    private final PostRepository postRepository;
    private final CommentRepository commentRepository;
    private final LikeRepository likeRepository;
    ...

현재 나의 PostService 객체이다. 보다시피 다양한 Repository를 참조하고 있다.

계층 설계를 다음과 같이 두었는데, 이런 식으로 한 서비스에서 다양한 레포를 참조한다면 서로간의 결합도가 생겨 좋지 않은 코드가 발생할 것이라고 생각했다.

이에 대해 고민하면서, Post 객체를 조회할 때, 왜 해당 게시글에 대한 Comment를 같이 조회하도록 구조를 설정했는지,
Post 객체를 삭제할 때, 왜 하위의 Comment, Like 등등의 모든 객체를 삭제하도록 설계했는지에 대한 생각을 더 하게됐다.

사실, PostService 객체는 Post와 관련된 행위만을 하도록 만들어놓았고, 다른 객체들도 객체만의 역할을 하기 위해 Service 계층을 분리해놓은 것인데, 그렇지 못하고 있다는 생각이 들었다.

객체에 대한 처리는 Service로 잘 분리해놓고, 객체에 대한 처리가 필요할 때는, 다른 계층에서 불러와서 처리하는 것이 아니라 그러한 역할을 하고 있는 Service 객체에게 해당 역할을 위임하여 사용하는 것이 낫지 않을까 생각했다.

그렇다면, Service 계층은 다른 Service 계층을 참조한다고 쳤을때, 순환참조가 일어날 때는 어떻게 할 것인가? 라는 질문이 자동으로 던져지는데,
이에 대한 대답은, 그렇게 된다면 프로젝트 설계 자체가 잘못되었다는 것이라 생각했다.

예를들어, Comment 객체는 Post 객체를 참조하고 있고, Post 객체는 Comment 객체에 대해 모르고 있는 상황이라고 생각하면,

PostService 에서도 CommentService에 대해 부탁할 것이 없다.
하지만, CommentService는 PostService에 대해 알고있는 것이 있기 때문에 부탁할 일이 생기므로 그러한 Service 간 연관관계가 성립하게 되는 것이고, 이를 어긋난다면 프로젝트 설계가 잘못되었다는 것이 생각이다.


02. 결론

이와 관련해 많은 사람들의 고민을 들을 수 있는 링크를 찾기도 했다.

링크: BE | Service에서 Service를 의존할까 Repository(Dao)를 의존할까 | 2022.05.24 #15

나의 생각과 달랐던 점은, CUD에 관해서는 Service 계층에 의존하는 것이 맞지만, Read 정도의 일은 Repository 단에서 처리도 문제 없다는 의견이 있다는 것이다.

하지만, 나의 생각은, 그렇게 Repository 를 결국 Read만을 위해 참조를 한다고 하더라도, 협업시에 Repository의 의존 이유에 대해 주석을 달아놔 꼭 읽어달라고 써놓을 수도 없는 노릇이라 최대한 다른 객체의 Repository를 참조하는 일은 지양하도록 해야겠다는 것이 나의 생각이다.

물론, 이렇게 된다면 메서드의 분리나 역할의 분리가 일어나 조금 더 번거롭겠지만 더 좋은 코드가 탄생할 것이라고 생각한다. 항상 Trade-Off는 존재하기 때문에, 이 외에도 다른 단점은 없는지 더 생각해봐야겠다.
(Transactional, DDD 등의 키워드 관련 문제 생각하기)

개발자 준비생의 짧은 생각이지만, 이렇게 프로젝트의 구조나 좋은 코드에 대해 더 생각할 수 있는 기회를 갖게 되어 좋은 경험이라고 생각한다.


03. 오늘의 한 문단

상황에 따른 정답을 생각해내자.

profile
코드 중심보다는 느낀점과 생각, 흐름, 가치관을 중심으로 업로드합니다!

0개의 댓글