What is Domain Service ?

When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as standalone interface declared as a SERVICE. Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LANGUAGE. Make the SERVICE stateless.

— Eric Evans Domain-Driven Design —

From: Domain Driven Design

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

도메인 서비스간 의존 관계는 최대한 제거:

도메인 레이어에 속하는 도메인 서비스간의 의존 관계는 최대한 제거하는게 좋다.

Benefits

  • 도메인 레이어에 대한 테스트 코드 작성이 쉽다.
    • Layered Architecture 에서 Domain Layer 에 대한 테스트 코드 작성이 가장 중요하다고 생각한다.
  • 도메인 서비스간에 상하 관계를 제거할 수 있다.
    • 서비스간의 참조 관계를 두다 보면, Root Service 에 많은 의존성이 생겨서 테스트 코드 작성이 어려워질 수 있다. 또한, 도메인 로직 파악이 어려워진다.

Implementation

  • 세세한 구현과, low-level 의 기술은 infrastructure 에 위임하고, 구현체를 사용하는 레이어에 interface 를 제공한다.
  • 해당 레이어에서는 DIP(Dependency Inversion Principle, 의존 관계 역전 원칙)를 통해 구현체를 사용한다.

Dependency Inversion Principle

  • 구현체가 아닌 추상화에 의존한다. (= 구현이 아닌 역할에 의존)
  • 추상화 레벨이 높은 상위 수준의 모듈이 추상화 레벨이 낮은 하위 모듈에 의존하면 안된다.
    • Domain Layer 가 상위 수준의 모듈, Infrastructure Layer 가 하위 수준의 모듈로 볼 수 있다.

DIP 를 적용했을때의 장점은 Portable Service Abstraction 의 장점과 같다.

서비스 추상화로 제공되는 기술을 다른 기술 스택으로 간편하게 바꿀 수 있는 확장성이 생긴다.

Naming

보통의 경우에는 application layer 에서 Facade 형식의 xxxService 라는 네이밍을 사용하는 컨벤션을 사용하곤 한다. 하지만 DDD 개념을 적용하여 개발하는 경우에는 다른 네이밍을 가져가는게 좋다고 생각한다.

  • Ex. xxxFacade, xxxApplicationService …

References

  • 도메인 주도 설계 / Eric Evans 저 / 위키북스