SERVICE

설계가 명확하고 실용적이더라도 개념적으로 어떠한 객체에도 속하지 않는 연산이 포함될 때가 있다. 이러한 문제를 억지로 해결하려 하기보다는 문제 자체의 면면에 따라 SERVICE를 모델에 명시적으로 포함할 수 있다.

도메인의 개념 가운데 객체로는 모델에 어울리지 않는 것이 있다. 필요한 도메인 기능을 ENTITY 나 VALUE 에서 억지로 맡게 되면 모델에 기반을 둔 객체의 정의가 왜곡되거나, 무의미하고 인위적으로 만들어진 객체가 추가될 것이다.

SERVICE 는 상태를 캡슐화 하지 않는다.

도메인의 중대한 프로세스나 변환 과정이 ENTITY 나 VALUE_OBJECT 의 고유한 책임이 아니라면 연산을 SERVICE 로 선언되는 도릭 인터페이스로 모델에 추가하라. 모델의 언어라는 측면에서 인터페이스를 정의하고 연산의 이름을 UBQUITOUS_LANGUAGE 의 일부가 되게끔 구성하라. SERVICE 는 상태를 갖지 않게 만들어라.

잘만들어진 SERVICE 의 세가지 특징

  1. 연산이 원래부터 ENTITY 나 VALUE_OBJECT 의 일부를 구성하는 것이 아니라 도메인 개념과 관련돼 있다.
  2. 인터페이스가 도메인 모델의 외적 요소의 측면에서 정의된다.
  3. 연산이 상태를 갖지 않는다.

SERVICE 를 어러 계층으로 분할하기


응용               자금이체 응용 서비스 ㄱ
                   -입력(xml 요청과 같은) 내용의 암호화
                   -이체처리를 위한 도메인 서비스로의 메시지 전송
                   -이체확인 대기
                   -인프라스트럭체 서비스를 이용한 통지 결정
    
도메인             자금이체 도메인 서비스
                   -금액 인줄/입금에 필요한 Account 와 Ledger 객체 간의 상호작용
                   -이체 결과 확인 정보 제공
    
인프라스트럭처     통지서비스
                   -애플리케이션에 지정한 곳으로 이메일이나 우편 등으로보냄