service-layer

To stop business logic leaking into controllers, extract orchestration steps into an Application Service. This isolates coordination logic, keeping controllers thin and ensuring business rules reside within domain objects or stateless domain services.

An Application Service orchestrates use cases as a thin coordination layer, while a Domain Service holds stateless business logic that spans multiple domain objects. Separating them prevents orchestration from diluting core domain rules.

You need a service layer in domain-driven design when use cases span multiple aggregates or require coordination across domain objects and infrastructure. It defines a public API boundary for clean application service orchestration.

Identify orchestration steps in your controller and extract them into an Application Service to coordinate domain objects. This establishes a clearly defined service boundary that separates coordination from expressive business rules.

Cross-entity domain logic should reside in stateless Domain Services, not application services. Placing rule-logic in domain services or entities keeps application services thin for orchestration and maintains domain cohesion.

Avoid placing business rules in application services. Application services should remain thin orchestration layers; business rule-logic belongs in domain objects or stateless domain services to keep entities cohesive and expressive.