Refactor : 중복 코드 제거하기 #189
Description
어떤 리팩토링인가요?
- 예를들어 한 서비스 안에서 UserRepository를 이용해 findById() 메서드를 호출하여 user 를 가져오는 중복 코드가 많이 존재한다
기존에 알았던 지식
- 3계층 아키텍처 : Controller -> Service -> Repository
- Service 계층 안에서 비즈니스 로직을 나누기 위해 여러 개의 repository를 사용했다
- 왜냐하면 service 간의 결합도나 계층 구조 때문이라고 생각했다
새로 알게된 지식 (고쳐먹게 된 지식)
-
Service 계층 안에서 비즈니스 로직을 나누기 위해 여러개의 서비스를 둘 수 있다.
-
서로 다른 도메인 로직을 담당하는 서비스가 필요에 따라 서로 호출하는 것도 흔히 일어나는 패턴이다.
-
하지만 여기서 중요한 점은 단방향 의존이여야 한다
-
ActivityLogService -> UserService 를 호출한다고 하면 또UserService -> ActivityLogService 를 호출 한다면 순환 의존성이 생겨난다
-
일반적으로 계층이 깨진다는 말은 : 하위 레이어 를 상위 레이어를 역으로 부르는 상황, 상위 레이어가 하위 레이어를 직접 부르는 상황
ex) 하위 레이어 를 상위 레이어를 역으로 부르는 상황 : Repository -> Service
ex) 상위 레이어가 하위 레이어를 직접 부르는 상황 : Controller -> Repository
결합도 문제는?
- service 에서 service를 호출 하면 당연하게 결합은 생겨난다
- 하지만 user를 가져오는 로직만을 호출한다는 점은 대부분의 서비스 간 호출에서 자연스럽게 발생하는 것이다.
- User 관련된 로직(예: User를 조회하고, 없으면 예외를 던지는 로직)을
별도의 UserService가 관리하도록 하여, ActivityLogService 안에서 중복을 줄이는 이점이 더 크다.
이에 대한 내 생각
- 객체 지향 적으로 역할과 책임을 생각 한다면 user를 찾기 위해 repository의 findById()를 호출하고 exception를 던지는건 UserService 클래스에서 하는게 더 자연스러운 현상인 것 같다.
- 계층 구조에 대해서 다시 한 번 이해 하게 되었다.
- AService 에서 BService를 참조 한다는 건 흔히 일어나는 패턴이지만 순환 참조만 피하면 된다는 것을 알게됨
Todo
- 중복 코드
- Service layer 를 구분하고 Service 간 의존하는데 의존성 방향을 고정하여 순환참조 방지하기