API의 추가 및 변경이 있을 경우
예를 들어 현재 서비스에 graphql을 도입하기로 결정했을 때 Controller에 모든 기능을 구현하였다면, Grapqhql API를 구현하는 Controller에 똑같은 기능을 또 다시 구현하여야 합니다.
하지만 다음 그림처럼 Service에 기능을 구현하였다면 GqlController를 새로 만들어서 Service에 연결만 해주면 됩니다.
또한 Service에 기능을 구현하게 되면 장점이 하나 더 있는데 점진적으로 API를 변경할 수 있다는 점입니다.
만약 Service에 기능을 추가하지 않고 Controller에 모든 기능을 구현하였다면 Controller의 API를 모두 수정하기 전까지 배포를 할 수 없지만
변경된 부분만 GqlController로 옮길 수 있으면 두 가지 API를 동시에 사용할 수 있어 점진적으로 서비스를 개선할 수 있습니다.
트랜잭션 처리
Spring에서 Service의 고유한 기능 중 하나는 Transaction 처리 기능입니다.
트랜잭션이란 DB 업데이트시 일련의 업데이트 과정을 완전히 성공하거나 완전히 실패하는 일련의 논리적 작업단위입니다.
은행 송금을 예로 들면 다음과 같습니다. 트랜잭션이 없는 상태의 송금 실패 시나리오 입니다.
DB에서 B의 계좌를 업데이트 하는 것을 실패했을 때 트랜잭션이 없다면 A의 계좌를 롤백하지 않아 A의 계좌에만 5000원이 감소하게 됩니다. 그러나 트랜잭션을 사용한다면 B의 계좌를 업데이트 하는 것을 실패했을 때 A의 계좌도 다시 롤백하기 때문에 실패시에도 안전하게 돈을 보존할 수 있습니다.
Service에서는 클래스나 메서드에 @Transaction을 사용하여 Exception이 발생할 경우 모든 DB업데이트를 롤백하는 과정을 가질 수 있습니다.
Controller와 Service의 역할
Spring Application Layered Pattern
Spring Application Layered Pattern은 웹 서비스를 만들 때 많이 사용하는 계층구조입니다. Spring에서 흔히 사용하는 계층 구조로써 Web Layer에서 사용자의 요청을 받고 Service Layer에서 실제 요청을 처리하고, Repository Layer를 통해 Data를 조회 변경합니다.
Controller는 Web Layer에 해당하고 Service는 Service Layer에 해당합니다.
Controller에서는 사용자의 입력처리와 응답에만 집중하고, Service에서는 실제 기능의 구현에만 집중한다면 협업할 때 다른 팀원이 코드를 수정할 때에도 어떤 기능이 어디에 있는지 쉽게 알 수 있고 변경이 유리합니다. 이는 단일 책임 원칙을 지키는 기본입니다.
