도메인 주도 설계 구현

서비스(Service)

도메인 내에서 서비스란 도메인 고유의 작업을 수행하는 무상태의 오퍼레이션이다.

도메인 모델에서 서비스를 생성할 필요가 있음을 알리는 가장 정확한 지표는 에그리게잇이나 값 객체 상에 수행해야 하는 오퍼레이션이
메소드로는 부적절하게 느껴질때이다. DDD를 사용하면 이런 전술의 코드에선 정적 메소드 대신 서비스를 사용하라는 냄새가 풍긴다.

도메인 서비스란 무엇인가?

도메인 서비스는 애플리케이션 서비스와 혼동해서도 안된다.

우리는 비지니스 로직을 애플리케이션 서비스 안에 넣으려는게 아니라. 비지니스 로직을 도메인 서비스 안에 넣고자 한다.
애플리케이션 서비스는 도메인 모델의 자연스러운 클라이언트로서 보통 도메인 서비스의 클라이언트가 된다.

때론 그건 정말 아무 대상도 아니다. 도메인 내의 유의미한 프로세스나 변형이 엔터티나 값객체의 자연스러운 책임이 아니라면
독립 인터페이스로서 서비스로 선언된 오퍼레이션을 모델에 추가 하자 모델의 언어로 인터페이스를 정의하고 
오퍼레이션 이름이 반드시 유비쿼터스 언어의 일부가 되도록 하자. 서비스를 무상태로 만들자

도메인 서비스의 사용 예

중요한 비지니스 프로세스를 수행할때
어떤 컴포지션에서 다른 컴포지션으로 도메인 객체를 변형할 때
하나 이상의 도메인 객체에서 필요로 하는 입력 값을 계산할때

서비스가 필요한지 확인하자

서비스로 도메인 개념을 모델링하는 데 너무 의존하지 말라. 상황이 적절할 때만 사용해야 한다.

클라이언트가 수행해야만 하는 비지니스적 책임은 다른 모든 세부사항을 다룰 단일 도메인 특정 오퍼레이션의 사용을 조정하는 일뿐
이럴때 서비스를 할용하자

도메인에서 서비스를 모델링하기

도메인 서비스의 목적이 먼지에 따라 도메인 내에서 서비스를 모델링하는 일은 아주 간단할수 있다.
서비스에 분리된 인터페이스가 있어야만 하는지 판단해야 한다 만약 필요하면 만들어야 한다.

분리된 인터페이스가 꼭 필요할까?

기술적인 구현이 없는데도 분리된 인터페이스와 구현클래스가 필요하고 이를 분리된 계층과 모듈에 담아야 할까?
사실 반드시 필요하진 않다. 이런 유형의 서비스를 단일 클래스로도 만들수 있다.

분리된 인터페이스는 결합 분리의 목표가 분명할때 유용하다.

계산 프로세스

계산은 언제나 같은 방식으로 수행된다. 상황이 변하지 않는 한 구현에서 인터페이스를 구분할 필요는 없다.

서비스의 테스트

우리는 클라이언트의 관점에서 생각하는 모델링 방향을 제대로 반영했는지 확인 하기 위해 서비스를 테스트 한다.

참조

implementing-domain-driven-design