자바스프링 개발자를 위한 실용주의 7. 서비스

서비스의 역할

• 도메인 객체를 불러온다.
• 도메인 객체나 도메인 서비스에 일을 위임한다.
• 도메인 객체의 변경 사항을 저장한다.

Manager

서비스를 이해하기 위해 Spring에서 서비스를 어떻게 정의하는지 보자.

@Service 주석 요약
“서비스는 도메인 주도 설계（DDD: Domain-Driven Design） 에서 시작된 개념으로 캡슐화된 상태 없이 , 모델과는 독립된 동작을 제공하는 인터페이스이다.”

DDD 창시자 에릭 에반스가 설명한 서비스
entity나 vo에서 찾지 못하는 중요한 도메인 연산이 있다. 이들 중 일부는 본직적으로 사물이 아닌 활동이나 행동인데, 우리의 모델링 패러다임이 객체이므로 그러한 연산도 객체와 잘 어울리게끔 노력해야 한다.

 

서비스는 DDD에서 시작됐고, 그 창시자는 도메인 객체가 처리하기 애매한 연산을 표현하도록 하는 컴포넌트로 설명했다.

 

삼품을 계산할 때, 여러 도메인이 필요하다. 유저, 상품, 할인정보 등. 그렇다면 3개의 도메인 중 어디서 계산을 하는 것이 맞을까? 셋 다 어색하다. 이때 도메인 서비스인 “manager”가 등장한다. 어디서도 처리하기 애매한 연산에 있어서, 이들을 잘 어울리게끔 하는 “PriceManager” 컴포넌트를 만드는 것이다.

 

 

Service 어노테이션의 두번째 주석이다.

@Service 주석 요약
“스프링 서비스는 J2EE의 비즈니스 서비스 파사드 패턴 처럼 사용할 수 있다.”

 

‘비즈니스 서비스 파사드 처럼’ 이라는 표현을 사용한다. 파사드 패턴을 간단하게 설명하자면, 인터페이스와 그것을 구현한 관계로 볼 수 있다. 이 의미에 대입해본다면, 인터페이스처럼 대문의 역할을 어플리케이션 서비스(@Service)가 한다. 그리고 그것의 구현체로 볼 수 있는 즉, 비즈니스 로직을 포함한 것은 도메인과 도메인 서비스에서 처리한다.

이렇게 되면 각자의 역할이 더 명확해진다.

• 애플리이션 서비스 : 도메인이 협력하는 공간
• 도메인 서비스 (manager) : 도메인에서 하기 애매한 비즈니스 로직 처리
• 도메인 모델 : 비즈니스 로직 처리

 

서비스보다 도메인 모델

 

앞서 도메인 서비스를 설명했다.

“도메인 모델이 처리하기 애매한 연산들을 도메인 서비스로 위임하는 것.”

 

이 말은 반은 맞고 반은 틀리다.

 

서비스를 만들기 보다는 풍부한 도메인 모델을 만들어내는 것이 더 좋다. 이전예로 보았던 PriceManager라는 도메인 서비스를 만드는 것 보다, Casher라는 도메인 모델을 만드는 것이다.

 

도메인, 서비스의 우선순위를보면 다음과 같다.

• 도메인 모델 > 도메인 서비스 > 어플리케이션 서비스

도메인과 도메인 서비스는 행동으로 결정된다. 접미어로 Service, Manager로 구분하는 것이 아니라 어떤 행동을 하느냐이다. 표현이 애매하다. 하지만 우선순위로 기준을 세웠으니, 순서대로 고민해보면 된다.

 

 

정리

서비스를 얇게 유지하고, 풍부한 도메인을 만들어라.

그렇기 하기 위해, 기존 도메인 객체에 들어갈 수는 없는지? , 새로운 도메인 모델로 만들 수는 없는지? 고민해야 한다.

 

작은기계

첫 번째 객체는 한번 생성하면 여러 번 사용하지만 그 자신은 바꿀 수 없다 . 생명 주기도 매우 단순하다 . 한번 생성하면 특정 작업을 하는 작은 기계처럼 영원히 실행할 수 있다 . 이러한 객체를 서비스라 한다．-마티아스 노박

 

서비스는 영원히 같은 기능을 하는 작은 기계여야 한다. 때문에 서비스는 불변해야 한다.

• 생성자 주입을 해야 한다.

생명 주기가 단순해야 한다.

• 서비스에 의존성을 추가할 때 신중하게 결정해야 한다.

 

서비스와 관련된 조언

• 서비스의 멤버 변수는 모두 final로 만들기
• 서비스에 setter 안쓰기
• 서비스는 반드시 생성자 주입으로 바꾸기
• 서비스의 비즈니스 로직을 도메인에 양보하기
• 서비스를 얇게 유지하기