Service 설명

[ Service 설명 ]

[ 서비스 (Service) 란? ]

서비스는 기능의 이름을 이야기한다.

컨트롤러는 외부 요청을 통신으로 받는 최초 진입점. 즉, api 주소를 가지고 있다.
(API의 엔드포인트 = URL)

실제로 내부에 서비스를 하고 싶을 때에는 그냥 받으면 되는데(?)
외부에 서비스를 제공할 수는 없어서 컨트롤러의 api 주소를 통해서 서비스를 제공하는 것
때문에 외부에 노출할 때에는 이 api 주소를 노출한다.
/join 하면 회원가입 하는.. /login 로그인 하는... API주소를 노출

그런데 이 회원가입의 '기능'은 어디에 있어야하나? 바로 서비스!
기능!!을 서비스에 제공

그러나
하나의 기능이 하나의 레파지토리로 해결 안 될 수도 있다. 
(=1대 1 매칭이 안될 수도 있다는 말)

예시를 들어보자

[ 예시 1 ]
콩나물을 먹는다 -> 콩나물을 먹는 것
삼겹살을 먹는다 -> 삼겹살을 먹는 것
이런 메소드들이 jpa 레파지토리에 순수하게 다 있는 것임.

실제 서비스라는 건 기능을 이야기함. 외부에 제공해야할 기능! (추상적)
저런 구체적인 콩나물, 삼겹살이 아니라 '밥먹다' 를 들고 있는 것임

서비스는 밥먹다라는 메소드... 
즉, 콩나물 먹기, 삼겹살 먹기 이런걸 조합해서 내는 것!
-> 조합해서 쓰기 때문에 1:1로 매칭이 안됨.  
-> 여러가지가 하나의 서비스니까! 트랜젝션 관리가 필수! 

[ 예시 2 ]
고객이 통닭, 콜라, 라면을 요청했다.
주문이라는 서비스가 생김.

내가 레파지토리(주방)에 가서 통닭, 콜라, 라면을 하나씩 만든다.
애도 필요하고, 애도 필요하고, 애도 필요하니까 레파지토리를 여러번 때림!

그러다가 라면 만들기를 실패함!! -> 2개만 배달 보내면 될까? 안 된다!
롤백하고 처음부터 다시 만들어야함! 하나하나씩 다시!! 

3개가 다 정상적으로 완료되었을 때 배달(컨트롤러)하는 사람한테 주는 것임 

[ 계좌 이체로 보는 서비스 ]

계좌 정보만 남아있으면 뭐가 뭔지 모르니까 히스토리 (거래내역)을 만든다.
(이 거래내역을 저장하는 히스토리 테이블이 필요)

JPA UPDATE로 send 계좌 한 번 UPDATE, 다시 receiver 계좌를 UPDATE,
다른 레파지토리에 접근해서 히스토리(거래내역)을 INSERT.
-> 이 3가지 로직을 하나의 서비스(기능)이라고 함!