In a DDD-layered backend, an application service method is often described as 'transaction, security, orchestration, DTO mapping — but no business rules.' What does each of those four responsibilities concretely mean in code, and why must business rules stay out of this layer?

## Four responsibilities, one layer Application services in DDD are often summarized by four responsibilities, and it's worth walking through what each looks like in real code, because each is a specific technical mechanism with its own reason for living at this layer rather than in the domain model: 1. **Transaction management** 2. **Security enforcement** (authorization) 3. **Orchestration** 4. **DTO mapping** ## Transaction management Transaction management is the most concrete: the application service method is where a unit of work is demarcated. - In many frameworks this is literally a method annotated as transactional. - In other stacks it might be an explicit `beginTransaction()`/`commit()`/`rollback()` pair. - Or a unit-of-work object passed down. The reason this lives here and not in the domain layer is that a single use case often needs to touch multiple aggregates atomically — e.g., debiting one `Account` aggregate and crediting another must either both succeed or both fail — and the domain objects themselves have no concept of "this write and that write happen together." If transaction boundaries were pushed down into domain services, you'd lose the ability to compose multiple domain operations into one atomic use case, because each domain service call would need its own transaction, defeating atomicity. ## Security enforcement Security enforcement (authorization) happens here because the domain layer typically doesn't know about the concept of a "current user" or a "request." The application service checks something like "does this authenticated principal have permission to cancel this order" — often by comparing the caller's identity/roles against data loaded from the aggregate — and rejects the call before any domain logic runs. Domain services and entities stay ignorant of security concerns entirely; they express business rules that would be true regardless of who's asking. This separation matters because **security policy changes independently of business rules** — you might add a new role or permission check without touching how order cancellation logic works internally. ## Orchestration Orchestration is the sequencing logic: 1. load aggregate A via its repository 2. call a method on it or hand it to a domain service along with aggregate B 3. save the result 4. publish whatever domain events resulted This is inherently procedural and use-case-specific — "place order" orchestrates differently from "cancel order" even though both touch the `Order` aggregate — so it doesn't belong on the aggregate itself. The application service is where these steps are visibly ordered, which is also what makes it easy to read a use case top-to-bottom. ## DTO mapping DTO mapping — translating between request/response objects (JSON bodies, gRPC messages, whatever the interface layer speaks) and domain objects — stays in the application layer because DTOs are shaped by the needs of a specific client/protocol, not by the domain's own structure. A `CreateOrderRequest` DTO might flatten nested value objects into primitive fields for easy serialization; if the domain model had to accommodate that shape directly, it would be distorted by transport concerns. Keeping mapping in the application service means the same domain model can serve a REST controller, a message-queue consumer, and a batch job without modification. ## Why business rules stay out Why must business rules stay out of all four of these? Because **a business rule needs exactly one home to be maintainable** — every additional place that duplicates or half-implements a rule is a place that can drift out of sync when the rule changes. If "an order can only be cancelled before shipping" is checked inside cancelOrder's application service method, and later a second use case ("bulk cancel") reimplements the same check slightly differently, you now have two divergent definitions of cancellability. Putting the check on the `Order` aggregate (`order.cancel()` throws if already shipped) means every use case that calls `order.cancel()` automatically gets the current, correct rule, and a unit test against the aggregate alone proves the rule works without needing a database, HTTP layer, or mocked security context. ## The production failure mode A production failure mode that shows exactly this: teams that build application services by copy-pasting an existing use-case method and modifying it for a new endpoint tend to also copy-paste the if-checks inside it, because those checks look like just more orchestration steps. Six months later, a rule change ("cancellation is now allowed up to 1 hour after shipping") requires hunting down and updating every copy, and it's easy to miss one — leading to an endpoint that silently applies stale business logic. Concretely, in an order-management system this often surfaces as a support ticket: "I cancelled through the mobile app and it worked, but the same cancel through the admin bulk-tool failed with an old error" — a direct symptom of the same rule being implemented twice at the wrong layer.