Domain service
A domain service makes visible a domain-language operation that combines several business facts.
- FactsFacts used by the rule.
- OperationNamed decision.
- OutcomeBusiness-readable output.
Context
Why this is important
Model and independently test business rules with no natural object owner.
A business calculation with explicit inputs; infrastructure and process coordination remain separate responsibilities.
Object behavior or domain service
The shipping-eligibility rule checks values from ordering, catalog and shipping options in the seven-module shop.
This is how you read the picture
- Facts Inputs
- Operation Policy
- Outcome Response
| Criterion | Policy | Suitable location |
|---|---|---|
| Direct invariant | Entity or value object | Entity or value object |
| Several facts | Domain service | Domain service |
Benefits & limitations
Helps if:
- A decision combines facts from several objects and belongs to none of them alone.
- A business operation needs a clear contract that can be tested independently.
Boundaries
- One service per entity creates procedural layers and scatters related rules.
- Infrastructure calls and process coordination belong in the appropriate application or integration components.
In practice
- State the rule in domain language as a decision with clear inputs and an outcome. Also note which missing or conflicting values require a business response.
- First check whether an Entity or Value Object has all relevant facts and can express the rule as its own behaviour. Consider a Domain Service only when no object is the natural owner.
- Pass the remaining facts through a narrow contract and return a business-named outcome. Test edge cases without a database or network, and keep side effects in an appropriate application layer.
Read the detailed explanation
The service expresses an operation such as “determine shipping eligibility.” It receives the facts needed by the rule and returns a business result. It has no long-lived state of its own and hides no database or network access.
If a rule clearly belongs to an entity or value object, keep it there. Rules spanning consistency boundaries need deliberate process coordination. A domain service is neither a generic application step nor automatically a distributed transaction manager.
First check whether the rule belongs to an Entity or a Value Object; the Aggregate defines its consistency boundary.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which facts does the shop rule check?
View the solution with justification
Weight, destination and shipping method.
ApplyingTransferred to a new situation
A rule naturally belongs to the cart. Where should it live?
View the solution with justification
As behavior of the relevant cart object.
EvaluateWeighing an alternative
When is a separate domain service justified?
View the solution with justification
When no object naturally owns the operation and its inputs and result are clear in domain terms.
Explore further
These building blocks continue the thoughts of this page.
References
- Eric Evans · DDD Reference (opens in new tab)Primary reference for tactical DDD patterns.
- DDD Reference · German translation (opens in new tab)German edition of Eric Evans’ reference.
- Vaughn Vernon · Implementing Domain-Driven Design (opens in new tab)Further treatment of modeling and domain behavior.