B(H)log Logo

B(H)log

기술적인 이야기와 일상

소개
Settings

Chats

연락처

GitHubLinkedIn이메일

DDD에서 도메인 서비스를 사용해야 하는 경우

2 분
도메인 서비스도메인DDD설계

개요

이 문서는 도메인 서비스를 언제 사용해야 하는지 정리한 것이다.

서론

도메인 서비스(Domain Service) 는 엔티티(Entity) 나 값 객체(Value Object) 에 자연스럽게 포함되지 않는 중요한 도메인 로직을 담당한다.
애플리케이션 서비스(Application Service) 가 유스케이스나 트랜잭션 흐름을 조율하는 반면, 도메인 서비스는 도메인 모델 내에서 핵심적인 비즈니스 규칙을 구현한다.

비즈니스 로직을 도메인 서비스 대신 애플리케이션 서비스에 넣으면,

  • 도메인 모델의 응집도 저하
  • 유지보수성 하락
  • 테스트 복잡성 증가
    와 같은 문제가 발생할 수 있다.

따라서 도메인 서비스를 도입해야 하는 시점을 아는 것이 깔끔한 DDD 설계에 필수적이다.

도메인 서비스를 사용해야 하는 경우

도메인 서비스 사용이 적절한 주요 경우는 다음 세 가지이다.

  1. 비즈니스 규칙이 여러 엔티티에 얽혀 있는 경우

    • 규칙이 여러 엔티티에 걸쳐 얽혀 있다면 단일 도메인 모델에 넣기 어렵다.
    • 이때 로직을 도메인 서비스로 분리하면 명확성과 유지보수성이 향상된다.

  2. 엔티티에 넣으면 역할이 부자연스러운 경우

    • 특정 규칙을 엔티티에 넣으면 역할이 모호해지거나 단일 책임 원칙(SRP) 을 위반할 수 있다.
    • 예: OrderPolicyDecisionService 를 Order 엔티티에 넣는 것은 부자연스럽다. 정책 결정은 주문(Order)의 직접적인 책임이 아니다.

  3. 상태 없이 로직만 존재하지만 도메인 개념이 명확한 경우

    • 도메인에 중요한 개념이 있지만, 상태 없이 로직만 존재하는 경우이다.
    • 예: 세금 계산, 할인 정책, 포인트 적립 정책 등.

마무리

도메인 서비스는 애플리케이션 서비스만큼이나 중요하다.
능숙한 DDD 설계자는 언제 애플리케이션 서비스를 쓰고 언제 도메인 서비스를 써야 하는지 판단하여, 비즈니스 로직을 적절한 위치에 배치해야 한다.
이렇게 해야 응집도, 유지보수성, 테스트 용이성이 모두 향상된다.