Stateless Logic

Sometimes, a business operation involves multiple entities or doesn't naturally belong to any single entity. This is where Domain Services come in.

1. Orchestrating Multi-Aggregate Logic

Imagine a FundsTransferService. It needs to check the balance of Account A and update the balance of Account B. Neither account should own the logic for transferring to another account. The Domain Service acts as a stateless orchestrator within the Core layer.

2. Domain Service vs Application Service

A **Domain Service** contains business logic. An **Application Service** contains coordinate logic (logging, transactions, security). Rule of thumb: If the logic is something a business expert would care about, it's a Domain Service. If it's about technical plumbing, it's an Application Service.

3. Architect Insight

Q: "Should I use Domain Services for everything?"

Architect Answer: "NO! This is a common trap that leads to 'Anemic Domain Models'. Always try to put logic inside your Entities and Value Objects first. Only reach for a Domain Service as a last resort when the logic is truly stateless or involves multi-aggregate coordination. Keep your entities 'fat' and your services 'thin'."