국민학교 프로젝트를 리팩토링하면서 많은 코드를 클린 코드 원칙에 맞춰 수정하기 위해 노력했습니다. 특히, OOP 원칙에 따라 작성하려고 노력했습니다. 이러한 과정 중, 처음 맞닥뜨린 문제는 Repository의 역할에 대한 고민이었습니다.
처음에 친구의 코드에서는 다음 코드가 service 계층에 작성되어 있었습니다.
Post post = postRepository.findById(postId)
.orElseThrow(NotFoundPostException::new);저는 Repository 단에서 처리하는 것이 중복을 최소화하고 서비스 단의 코드를 간결하게 만들 것이라고 생각하여, Repository 단에서 처리하는 것이 어떠냐고 친구에게 제안했습니다.
친구는 메서드를 private으로 만들어 사용하는 것이 어떻겠냐고 물어보았고, 저는 다른 도메인에서도 필요할 수 있으니 Repository 인터페이스를 만들어 RepositoryImpl을 실체화하여 이용하는 것이 어떻겠냐고 제안했습니다.
이러한 고민사항을 현업에 계신 분께 질문했습니다. 현업자께서는 Repository 단은 데이터를 가져오는 역할 하나만 해도 충분히 어렵기 때문에 너무 많은 책임을 주는 것은 적합하지 않다고 하셨습니다. 또한, NotFound와 같은 예외는 보통 비즈니스 로직에서 처리하는 것이 더 적합하다고 조언해주셨습니다.
📌 결론
Repository는 DB에 접근하여 데이터를 가져오는 역할만 하면 되고, 그 외의 일들은 Service에서 처리하는 것이 좋다!
중복을 최소화하기 위한 목적 하나만 가지고 리뷰를 시작했지만, 이를 통해 객체지향적으로 바라보는 고민을 하게 되었고, 시야를 넓혀 객체지향에 대한 통찰력을 조금 얻을 수 있었습니다.
