Domain과 service의 차이
이 전에 entity와 domain 관련 을 정리하다 보니 Domain 과 service 를 잘 구분해서 쓰는지 다시 정리 할 필요 가 있어 글을 쓰게 되었다.
도메인 주도 설계(Domain-Driven Design, DDD)에서 Domain과 Service는 핵심적인 개념이지만, 그 역할과 책임에는 중요한 차이가 있다. 이 둘의 관계를 명확히 이해하면 시스템의 구조를 더 깔끔하게 만들고, 유지보수성을 높일 수 있다.
1. Domain(비즈니스의 본질)
Domain은 특정 비즈니스의 문제 영역 그 자체를 의미.
이는 단순한 코드가 아니라, 우리가 해결하려는 비즈니스에 대한 모든 지식, 규칙, 개념을 포함하는 추상적인 개념의 집합
- 역할: 비즈니스의 핵심 로직과 규칙을 담는 시스템의 '심장'입니다. 기술적인 구현 방식이나 외부 시스템에 의존하지 않는 순수한 비즈니스 개념으로 구성됩니다.
- 구성 요소: 도메인은 Entity(예: 회원, 상품), Value Object(예: 주소, 금액), Aggregate(관련된 엔티티와 값 객체의 묶음) 등 비즈니스에 직접적으로 관련된 객체들로 이루어집니다.
- 예시: '전자상거래 도메인'에는 '상품', '주문', '결제'와 같은 개념과 "재고가 없으면 주문할 수 없다"와 같은 비즈니스 규칙이 포함됩니다.
2.Service(행위와 오케스트레이션)
Service는 특정 기능을 수행하는 '행위'를 담당하는 객체
서비스는 그 자체로 비즈니스 규칙을 담기보다는, 도메인 모델의 객체들을 활용하여 특정 작업을 수행하는 역할
DDD에서는 이 역할을 크게 두 가지로 나눈다.
- Application Service (애플리케이션 서비스)
- 역할: 사용자 요청을 받아 도메인 객체들을 조합하여 요청을 처리하는 절차(오케스트레이션)를 담당합니다.
- 특징: 비즈니스 로직을 직접 구현하기보다 도메인 객체에 일을 위임합니다. 트랜잭션 관리, 보안, 로깅 등 기술적인 처리를 맡거나 외부 시스템(결제 API, 이메일 시스템)과의 통신을 조율합니다.
- 예시: "상품 주문하기" 요청이 오면, 애플리케이션 서비스는 회원 엔티티와 상품 엔티티를 불러와 주문을 생성하고, 결제 시스템을 호출한 다음, 주문 완료 이메일을 보내는 일련의 과정을 처리합니다.
- Domain Service (도메인 서비스)
- 역할: 하나의 엔티티에 속하기 어려운, 여러 엔티티 간의 협력이 필요한 비즈니스 로직을 구현합니다.
- 특징: 상태를 가지지 않는 연산 중심의 객체로, 순수하게 도메인 로직만 다룹니다.
- 예시: "계좌 이체"는 출금 계좌와 입금 계좌라는 두 개의 엔티티가 필요하므로, 이 로직은 TransferService와 같은 도메인 서비스에 속하는 것이 자연스럽습니다.
3. 주요 차이점
| 구분 | Domain | Servcie |
| 역할 | 비즈니스 문제 영역의 정의 | 비즈니스 로직 실행하는 행위 정의 |
| 성격 | 추상적, 개념적 | 절차적, 행위적 |
| 구성 | Entity, Value Object 등 상태를 가진 객체 | 메서드(동작)중심 객체 |
| 위치 | 시스템 핵심 레이어 | 주로 애프레케이션 레이어 |
| 예시 | 주문, 상품 개념 | 상품 주문하기, 결제 완료 처리하기 같은 동작 |
| 관계 | 서비스는 도메인을 활용하여 동작 | 도메인은 서비스가 처리할 데이터와 로직 제공 |
글을 쓰면서도 경계가 모호하다 보니 헷갈리기 쉽다는 생각이 든다.
Domain은 '무엇을 할 것인가'에 대한 정의와 규칙이다. 이는 비즈니스의 심장과 같습니다.
반면에 Service는 '그것을 어떻게 할 것인가'에 대한 절차와 책임이다.
이 둘의 역할을 명확히 구분함으로써, 우리는 비즈니스 규칙이 기술적인 코드와 섞이지 않고 순수하게 유지되는 시스템을 만들 수 있다.
이는 시스템의 유지보수를 쉽게 만들고, 비즈니스 요구사항 변경에 유연하게 대응할 수 있도록 돕는다.