Controller & Service & Repository role setting

1. 컨트롤러(Controller)

   - 클라이언트에서 요청한 데이터 검증

   - 클라이언트 응답 DTO(Data Transfer Object) 생성

 

2. 서비스(Service)

   - 비즈니스 유효성 검증

   - 비즈니스 로직

 

3. 리포지토리(Repository)

   - DB 조회

 

컨트롤러, 서비스, 리포지토리의 역할에 대해 논의하였다.

 

컨트롤러의 역할이 많이 달라졌다.

이전에는 들어온 요청을 서비스로 전달하는 역할만을 가졌다면,
이제는 클라이언트가 요청한 데이터의 유효성을 검증하고,
서비스가 DTO를 만들어 리턴하는 것이 아니라, 앤티티로 리턴하고, 컨트롤러에서 DTO를 만든다.

 

이렇게 한 이유는, 컨트롤러와 서비스의 역할을 명확히 구분하기 위함이었다.

서비스는 비즈니스 로직만을 담당하게 하고,
컨트롤러는 서비스가 비즈니스 로직을 수행할 수 있도록 클라이언트와의 역할을 담당하게 하였다.

 

먼저, 컨트롤러는 클라이언트에서 요청한 데이터를 검증하고

서비스에 전달하아 서비스가 비즈니스 로직을 수행한다.

 

컨트롤러가 하는 '데이터 검증'은,

예를 들어 고객(환자)의 코멘트를 조회하는 API라면,
기관(병원) 아이디, 유저(의사) 아이디, 고객(환자) 아이디로 데이터의 유효성을 검증하는 것이다.

 

고객(환자)의 코멘트를 조회하는 비즈니스 로직은 고객(환자) 아이디의 아이디만을 필요로 한다.
그러나 고객(환자)가 해당 유저(의사)에 속한 고객(환자)이 맞는지 검증되어야 한다.
또한, 유저(의사)는 해당 기관(병원)에 속한 유저(의사)가 맞는지 검증되어야 한다.

 

컨트롤러는 이와 같은 비즈니스 로직 외적인 유효성을 검증하고, 서비스로 전달한다.

 

서비스는 클라이언트에서 요청한 데이터가 유효하다는 전제 하에 비즈니스 로직만을 수행하면 된다.

 

그러나, 기획 정책적인 유효성은 서비스에서 검증한다.
예를 들어, 환자의 코멘트를 하루에 한번만 등록해야 한다는 정책이 있다면,
이와 같은 기획적인 프로세스 검증은 서비스에서 한다.

 

서비스를 통해 비즈니스 로직이 수행된 뒤에,

컨트롤러가 다시 클라이언트 응답 DTO를 만든다.

 

이렇게 함으로써, 서비스의 재사용성도 늘어나게 된다.

 

DTO를 리턴하는 서비스를 다른 서비스에서 이용하려면 앤티티를 리턴하는 서비스가 추가로 필요했다.

그러나 응답 DTO를 컨트롤러에서 만든다면, 서비스에서의 불필요한 코드가 줄어든다.

 

서비스에만 집중되었던 로직이 컨트롤러, 서비스, 리포지토리의 의미에 맞게 분배되어
역할적 관점에서 명확하고 실용적인 측면에서도 개선될 것 같다.