Domain vs. Application Services

1. The Core Distinction: "How" vs. "What"

At the heart of the distinction between Application and Domain Services is the separation of how an operation is performed from what the operation entails in terms of business rules.

• Application Services are concerned with the "how." They orchestrate the steps required to fulfill a specific use case or user request. Think of them as the project managers of your application's features.
• Domain Services are concerned with the "what." They encapsulate significant, stateless business logic that doesn't naturally belong to a single Entity or Value Object. They represent core business knowledge.

To get a quick overview, let's watch a short segment from a video that introduces these concepts within the context of a DDD project structure.

As the video illustrates, these services live in different layers of the architecture, which reflects their different responsibilities. Application Services are closer to the "outside world" (UI, APIs), while Domain Services are deep inside the core domain model.

2. Application Services: The Orchestrators

An Application Service's primary job is to handle a single use case. It coordinates the various components needed to complete a task, such as:

1. Receiving input data (often as Data Transfer Objects, or DTOs).
2. Retrieving one or more aggregates from a repository.
3. Invoking methods on those aggregates or calling a domain service to perform business logic.
4. Using a repository to save any changed aggregates.
5. Notifying other parts of the system (e.g., by publishing domain events or sending emails).

Crucially, an Application Service does not contain business logic itself. It delegates that responsibility to the domain model (Aggregates and Domain Services).

To see this in action, the following video provides an excellent example of the Application Layer's role.

In the video's example, the create bank account use case is a perfect candidate for an Application Service. It orchestrates calls to a government service and the database but doesn't decide whether the user is eligible—that's a core business rule.

3. Domain Services: The Keepers of Core Logic

So, where does that eligibility logic go? If a business rule is complex and involves multiple domain objects (e.g., checking a customer's credit score against their order history to approve a loan), it doesn't neatly fit into a single Aggregate. Placing it in an Application Service would pollute the orchestrator with core business logic.

This is where Domain Services come in. They are created for domain operations that feel like verbs without a natural home on an entity—concepts that, as Eric Evans puts it, "just aren't a thing."

A proper Domain Service has three key characteristics:

1. The operation relates to a domain concept but doesn't naturally belong to a single Entity or Value Object.
2. Its interface is defined purely in terms of other domain model elements (Entities, Value Objects).
3. It is stateless. It performs a calculation or operation and returns a result, but it doesn't hold any state of its own.

Let's return to the previous video to see how the Domain Layer complements the Application Layer.

The video highlights that the decision of whether a user is eligible to open an account belongs in the domain layer. A CustomerEligibilityService would be a perfect example of a Domain Service. It might take a Customer object and a CreditReport object and return a boolean result, without ever touching a database or sending an email.

4. A Deeper Dive: Location, Dependencies, and Examples

To solidify these concepts, let's examine a detailed article that provides clear definitions and code examples.

After reading, consider these points from the examples:

• The Domain Service (AccountOpeningService) is pure. It has a single method, validateAccountOpening, that contains a business rule (validateMinimumBalance). It has no dependencies on repositories or event publishers. It lives entirely within the domain.
• The Application Service (OpenAccountUseCase) is an orchestrator. It depends on the domain service, a repository, and an event publisher. Its execute method defines the workflow: create an account object, delegate validation to the domain service, save the result via the repository, and publish an event.

This clear separation makes the system much easier to test and maintain. The core business logic in the Domain Service can be unit-tested in isolation, while the Application Service can be tested to ensure it correctly coordinates the different components.

For a final, concise summary, let's look at another resource that provides a handy "cheat sheet."

The example of a TaxCalculationService (Domain) vs. an AccountExportService (Application) is another great illustration of the difference in their responsibilities.

Conclusion

Today we've unpacked the distinct roles of Application and Domain Services, a critical pattern for maintaining separation of concerns in a DDD architecture.

Here are the key takeaways:

• Application Services orchestrate use cases (the "how"). They live in the Application Layer, coordinate domain and infrastructure components, and are the direct clients of the domain model for executing user-facing tasks.
• Domain Services encapsulate core business logic that doesn't fit in a single Entity or Value Object (the "what"). They are stateless, live in the Domain Layer, and should be completely ignorant of infrastructure concerns like databases or APIs.
• This separation ensures your core domain logic remains pure, portable, and highly testable, while application-specific workflows are managed cleanly in a separate layer.

In our next lesson, we will put this theory into practice. We will implement a stateless Domain Service in Python to handle a business rule that spans multiple aggregates, and then we'll create an Application Service to orchestrate its use.