Application vs Domain Services

## The layers in play To understand the split, start with the layers a typical DDD application uses: - an **interface layer** (controllers) - an **application layer** (application services) - a **domain layer** (entities, value objects, aggregates, domain services, domain events) - an **infrastructure layer** (repository implementations, external clients) Each layer has one job, and the application-vs-domain-service question is really about which of two adjacent layers a given piece of code belongs in. ## The application service is a use-case orchestrator An application service is a use-case orchestrator. When a controller receives a request like "place order #123," it doesn't talk to the database or run business rules itself — it calls an application service method, e.g. `placeOrder(orderId, customerId)`. That method's body is a short, procedural script: 1. begin a transaction 2. check the caller is authorized to place orders for that customer 3. load the `Customer` and `Cart` aggregates via their repositories 4. ask the domain to do the actual work 5. save the result 6. publish any domain events 7. translate the return value into a response DTO None of these steps encode business rules — they encode **process**: what has to happen, in what order, for this use case to run safely. The application service is intentionally **thin**: if you find yourself writing an if-statement that decides whether an order is allowed to ship based on inventory levels, that's business logic and it has leaked into the wrong layer. ## The domain service holds rules with no single owner A domain service, by contrast, lives inside the domain layer and holds business logic — but only the kind that doesn't belong to a single entity or value object. Most business rules should sit directly on the aggregate they concern: an `Order` aggregate should have a method like `order.addLine(product, quantity)` that enforces its own invariants (e.g., can't add lines after checkout). But some operations genuinely span multiple aggregates, or represent a domain concept that reads as a process rather than a property of one object. - **A classic example** is transferring money between two `Account` aggregates: the debit and credit have to be coordinated, and neither account "owns" the transfer — so a `MoneyTransferService` domain service exists to hold that rule. - **Another common case** is anything requiring an external policy that isn't naturally a method of one entity, like calculating shipping cost based on a `PricingPolicy` that varies by season, region, and customer tier — the policy is business logic, but it doesn't belong to any single `Order` instance, so it becomes `ShippingCostCalculator`, a domain service, injected with whatever value objects it needs and returning a value object as its result. ## Why the split matters operationally The two matter operationally because of **transactions** and **testability**. - **Application services are the transaction boundary.** They own the transactional annotation or equivalent, they know about security context, and they're where DTO mapping happens because DTOs are an application-layer concern (the domain layer should never know about a JSON representation of itself). - **Domain services, meanwhile, should be pure with respect to infrastructure:** no direct SQL, no HTTP calls, no knowledge of the current user or request. They take domain objects in and domain objects out, which makes them trivially unit-testable — you construct value objects and aggregates in memory and assert on the returned value, no database or mocking framework needed. If a "domain service" method signature includes a database connection, an HTTP client, or a raw security-context object, that's a strong sign it's actually infrastructure/application code wearing a domain-service name tag. ## Getting it wrong, in both directions The trade-off of getting the split wrong runs both ways. | Failure direction | What it produces | |---|---| | Push too much into the application service | You get a transaction script — long procedural methods full of if-statements checking business rules, duplicated across every use case that touches the same aggregate, because there's no single owner for the rule. This is the classic symptom of an **anemic domain model**: entities become plain data bags (getters/setters only) and all the intelligence lives in services, which defeats the purpose of modeling the domain at all. | | Push too much into domain services | You get **"service-itis"** — a domain service for every single operation, even ones that clearly belong to one entity, which fragments behavior away from the data it operates on and makes the model harder to reason about; callers now have to know which of a dozen domain services to call for a given entity instead of just calling a method on the entity. | ## A concrete example A concrete real-world example: in an e-commerce system, `CheckoutApplicationService.checkout(cartId)` is the application service — it: - starts a transaction - loads the cart - calls `cart.finalize()` (an aggregate method enforcing "cart must have at least one item") - calls a `PriceCalculator` domain service to apply promotions that depend on both the cart and an external `PromotionCatalog` - saves the resulting `Order` aggregate - returns an `OrderConfirmationDto` The rule "a cart needs one item to be finalized" lives on the aggregate; the rule "promotions combine using this precedence" lives in the domain service, because it isn't the responsibility of any single aggregate.