예외처리와 의존성을 리팩토링
1. 컨트롤러 역할에 관련된 리팩토링
2. 리포지토리-서비스 간 의존성 스파게티 개선
친구 추가 기능이다.
사용자를 찾고, 찾아오면 친구로 등록한다. 도중에 사용자를 찾을 수 없으면 오류를 출력하고, 이미 친구로 등록되어 있는 사용자거나 자기 자신일 경우 역시 오류를 출력한다.
먼저 컨트롤러단에서 예외출력하는 것을 서비스 레이어로 옮겨보겠다.
정답이 있는건 아니지만 이 경우에 예외처리 부분을 옮겨보려는 이유는 다음과 같다.
컨트롤러에서는 클라이언트의 요청만 처리하게 하고 싶다.
컨트롤러 레이어는 클라이언트의 요청을 받아들이고, 응답을 내주는 레이어이다. 따라서 요청과 응답에 대해서만 처리하고 싶다. 예를 들어 클라이언트에서 허용되지 않는 입력을 요청했다면, 그건 컨트롤러 레이어에서 예외처리를 하고 싶다. 하지만 이 외의 로직들은 서비스의 정책이 변경되면 코드도 변경되어야 하는데, 정책의 변경으로 컨트롤러 레이어를 수정하고 싶진 않다. 또한 현재 코드는 비즈니스 로직이 컨트롤러 레이어에만 있는것도 아니고 사비스 레이어와 컨트롤러 레이어에 어중간하게 걸쳐있기 때문에 굉장히 별로라고 생각이 되었다. 또한 컨트롤러 레이어의 메소드가 복잡하다보니, 어떤 요청에 연결되어 있는지 알기 힘들고, 이 때문에 메소드 위에 주석을 달게 되는 일이 생겨버렸다.
정답은 없겠지만 일관성을 유지하고 싶었고, 일관성을 유지하기 위해서 컨트롤러 레이어에는 요청과 응답만 처리하고, 비즈니스 로직과 예외처리에 관련된 부분은 서비스 레이어에 맡기는 것으로 통일하기로 했다.
또한 현재 한 컨트롤러에서 여러 서비스에 의존하고 있다.
일부 서비스 레이어에서는 자신과 연관있는 리포지토리와 다른 서비스를 의존하고 있다.
컨트롤러 레이어에서 여러 서비스를 의존하거나, 서비스 레이어에서 여러 서비스에 의존하도록 통일하고 싶단 생각을 했다. 기존의 규칙이 없는 방식대로라면 한 컨트롤러가 모든 서비스를 의존하는 일이 생길 수 있고, 또 동시에 한 서비스가 모든 서비스를 의존하는 등 의존성이 복잡해질 여지가 있기 때문이다.
현 상황에선 서비스 레이어에서 비즈니스 로직과 예외처리를 하도록 결정했으니, 서비스 레이어에서 역할 수행에 필요한 여러 서비스와 자기 자신과 관련된 리포지토리 하나만를 의존하도록 하고, 컨트롤러 레이어는 자기 자신과 관련있는 서비스 하나만 의존하도록 다수의 의존성을 완화하도록 하겠다.
또한 예외를 ExceptionHandler가 존재함에도 불구하고 직접 처리하고 있다. 어떤 예외는 ExceptionHandler를 사용하고, 어떤 예외는 ExceptionHandler를 사용하지 않는다면, 나중에 코드를 다시 볼 때 이해가 되기 매우 힘들것이다.
또 두가지 예외를 한번에 처리하고 있으며, 출력 메세지도 오류가 있다. (이미 존재하는 사용자가 아니라 이미 친구인 사용자)
변경된 코드는 다음과 같다.
컨트롤러 레이어의 메소드가 얇아지고 거기 있던 코드가 서비스 레이어로 들어갔다.
