사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/yonatankarp/software-design-skills --skill ddd-domain-service시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
One-line summary
A domain service is a stateless operation in the domain layer that doesn't naturally sit on a single entity or value object — usually because it coordinates multiple aggregates or involves a domain computation that isn't anchored to one thing.
When to use this skill
- A cohesive domain operation involves multiple aggregates (e.g., transferring money between two
Accountaggregates). - A calculation involves domain types but isn't naturally a method on any of them (e.g., currency conversion, given exchange rates).
- Forcing the behavior onto one of the participating entities would make that entity "know too much" about the others.
When NOT to use this skill
- The logic fits cleanly on a single entity — put it there.
- The work is application-layer orchestration (handling a use case, opening a transaction, calling repositories) — that is an application service, not a domain service.
- The work is infrastructure (HTTP calls, database access, message sending) — that is an infrastructure service.
Core content
Three kinds of services often coexist in a DDD codebase. Keep them distinct:
Domain service. Lives in the domain layer. Operates on domain types only. Stateless. Expresses a verb in the ubiquitous language — TransferService.transfer(fromAccount, toAccount, amount), not AccountUtils.handleTransfer(...).
Application service. Orchestrates a use case. Opens transactions, calls repositories, invokes domain services, dispatches events. Stateless. Lives in the application layer.
Infrastructure service. Talks to the outside world — sends HTTP, writes to a database, publishes to a queue. Lives in the infrastructure layer.
A domain service is named for what it does in domain terms. TransferService and ExchangeRateConverter are good names. TransferManager and TransferHelper are smells — they hide the verb behind technical noise.
Decision heuristics
- Prefer entity behavior. Reach for a domain service only when the operation involves multiple aggregates or has no natural home.
- If a domain service has state, it is almost certainly misclassified — make it a domain entity, a value object, or move the state into one of the participating aggregates.
- If a domain service grows to dozens of methods, it is probably a "transaction script" in disguise — split it or push behavior back onto entities.
Anti-patterns
*Servicesuffix on every class — the domain becomes a collection of transaction scripts over data DTOs (see anemic-domain-model inddd-anti-patterns).- Putting infrastructure (database, HTTP) inside a domain service — couples the domain to deployment concerns.
- Domain services that mutate the entities they are given without going through the entity's methods — bypasses invariants.
- Stateful "services" that hold caches, sessions, or other process state.
See also
ddd-entity— first preference is to put behavior here.ddd-aggregate— domain services often coordinate across aggregates.ddd-anti-patterns— anemic-model and service-explosion smells.
References
- Evans, Domain-Driven Design (2003), Ch. 5 (A Model Expressed in Software).
