[TIL, 일일 회고] 2024.11.07 - DDD에서 도메인 서비스와 애플리케이션 서비스를 나누는 이유

 

 

개요

GlowGrow 프로젝트는 MSA 기반의 멀티모듈이자 DDD를 적용한 프로젝트였습니다.

 

이 때 DDD를 처음 접하다 보니, 도메인 서비스와 애플리케이션 서비스를 나누는 이유에 대해서 몰랐고 본 글에서 정리하고자 합니다.

 

 

DomainService란❓

도메인 서비스는 특정 엔티티나 값 객체에 속하지 않는 도메인 로직을 수행하는 서비스입니다. 순수하게 비즈니스 로직만을 담당하며, 외부 의존성이 없는 것이 특징입니다.

 

도메인 모델은 주로 엔티티와 값 객체(Value Object)로 구성되지만, 모든 비즈니스 로직을 개별 엔티티에 포함시키기에는 비효율적이거나 도메인 모델이 지나치게 비대해질 수 있습니다.

 

이런 경우, 개별 엔티티로는 처리하기 어려운 비즈니스 로직을 도메인 서비스로 옮겨서 관리합니다.

 

DomainService 특징

 

• 비즈니스 규칙을 담고 있으며, 한 엔티티에 종속되지 않은 로직을 처리합니다.
• 순수하게 도메인에 집중하며, 외부 기술이나 인프라에 의존하지 않습니다.
• 상태 변경보다는 비즈니스 규칙에 따른 결과 제공에 중점을 둡니다.
• 일반적으로 상태 비저장입니다. 입력을 받고, 작업을 수행하고, 해당 입력을 기반으로 결과를 반환하지만 장기적인 상태를 유지하지는 않습니다.

 

 

ApplicationService란❓

애플리케이션 서비스는 사용자의 요청을 처리하고 도메인 객체들을 조율하는 역할을 합니다. 트랜잭션 처리, 보안, 외부 시스템과의 통합 등 기술적인 문제를 다룹니다.

 

ApplicationService 특징

• 애플리케이션의 흐름을 담당하며, 여러 도메인 모델과 도메인 서비스의 조합을 통해 비즈니스 요구사항을 구현합니다.
• 트랜잭션을 관리하고, 외부 API 호출 등의 인프라 레이어와의 상호작용을 다룹니다.
• 주로 비즈니스 로직이 아닌 유즈케이스 로직을 포함하며, 도메인 모델을 사용하여 작업을 수행합니다.

 

 

DomainService와 ApplicationService를 나누는 이유

도메인 서비스와 애플리케이션 서비스를 분리하는 이유는 도메인 로직의 응집도를 높이면서 애플리케이션의 복잡도를 관리하기 위함입니다. 각각의 역할을 분리함으로써 얻는 주요 이점은 다음과 같습니다

 

1. 관심사의 분리

 

• 도메인 서비스
  • 순수한 비즈니스 로직에만 집중
• 애플리케이션 서비스
  • 트랜잭션, 보안, 통합 등 기술적 문제 처리

 

2. 재사용성 향상

 

• 도메인 서비스는 순수 비즈니스 로직만 포함하므로 다른 컨텍스트에서도 재사용 가능
• 예를 들어, 할인 계산 로직은 주문, 장바구니, 견적 등 여러 곳에서 재사용 가능

 

3. 테스트 용이성

• 도메인 서비스는 비즈니스 로직만을 다루므로 단위 테스트가 쉽고, 애플리케이션 서비스는 유즈케이스에 대한 통합 테스트를 수행할 수 있습니다.

4. 도메인 모델의 순수성 보장

• 비즈니스 로직을 도메인 서비스에 집중시켜 도메인 모델의 일관성을 유지합니다.

5. 유지보수성 향상

 

• 비즈니스 로직 변경 시 도메인 서비스만 수정
• 기술적 요구사항 변경 시 애플리케이션 서비스만 수정