Domain Service vs Application Service in DDD

Two different 'services'

DDD uses 'service' for two very different things.

Domain service: lives in domain layer. Holds domain logic that doesn't fit on any single entity or value object. Typically across multiple aggregates. Stateless; pure domain code; no Spring, JPA, HTTP. Named in domain language — PricingPolicy, FundsTransferService, RouteCalculator.

Application service (= use case / interactor): lives in application layer. Orchestrates one user goal end-to-end. Loads aggregates from repositories, invokes domain logic, saves, publishes events. Owns transaction boundary. Knows about infrastructure concerns but not their implementation. Named after the goal — PlaceOrderUseCase, CancelSubscriptionUseCase.

Rule of thumb: if it knows about repositories or transactions, it's an application service. If it just operates on domain objects, it's a domain service — or it should be on an entity.

When to use a domain service

Test 1: could this method live on an entity? If yes, put it on the entity. order.cancel() belongs on Order, not OrderCancellationService.

Test 2: does it operate across multiple aggregates? Yes → candidate for domain service. transfer(fromAccount, toAccount, amount) touches two Account aggregates.

Test 3: domain rule/policy with no natural home? TaxCalculator with jurisdiction lookups, PricingPolicy varying by tier and season. Domain logic but not bound to a specific entity.

If none of the above, you don't need a domain service. Most logic on entities or value objects.

Domain service example

FundsTransferService.transfer(from, to, amount) checks from.canDebit(amount), calls from.debit(amount), to.credit(amount). No @Service, no Spring, no @Transactional, no repository calls. Operates on already-loaded aggregates.

Application service is what loads/saves: TransferFundsUseCase pulls Account aggregates from repository, calls transferService.transfer(from, to, amount), saves both. @Transactional on use case.

Clean split: use case handles I/O and transactions; domain service handles the domain rule.

Application service — thin orchestration

Application services are thin. Their job is plumbing:

1. 1
   Pull aggregates via repositories
2. 2
   Delegate to entities / value objects / domain services
3. 3
   Persist the result
4. 4
   Publish domain events
5. 5
   Manage transaction boundary

PlaceOrderUseCase.execute(cmd): construct Order, reserve inventory, order.submit(), orderRepo.save(order), events.publishAll(order.drainEvents()), return order.id().

No business logic in this method. Every business decision (cancel, submit, addItem) lives in Order or a domain service. The use case is a script: load, decide via domain, save, emit.

The anti-pattern: logic in application services

Developers default to Spring @Service and pour business logic in. OrderService.cancel(id) loads order, checks if SHIPPED, sets CANCELLED, saves. Now business rule duplicated in every cancel flow (refund, admin, scheduled). Order is anemic; invalid state reachable via setStatus from anywhere. Fat service classes accumulate dozens of methods.

Fix: push rule into entity. Order.cancel() checks status, mutates, raises event. CancelOrderUseCase loads, calls o.cancel(), saves, publishes events.

Common mistakes

• Calling everything 'a service' — OrderService doing cancellation rules + HTTP→DB mixes layers
• Domain services for everything — most logic belongs on entities
• Application services with business logic — anemic entities + fat services = classic anti-pattern
• Domain services with @Transactional or repositories — they should know about domain objects only
• One huge OrderService — split by use case
• Domain service that's actually a calculator — fine as static method on value object
• Confusing 'domain service' with Spring @Service — stereotype doesn't tell you which kind

Recommendation

Default to putting logic on entities and value objects. Reach for a domain service only when the logic genuinely spans multiple aggregates or has no natural home. Application services (use cases) are thin orchestrators — one per user goal — that load aggregates, delegate to domain logic, save, and publish events. Application services contain no business rules; domain services contain no infrastructure concerns. Spring's @Service annotation tells you nothing about layer; the package and dependencies do.