Encapsulating Business Policies and Processes

A primary concern for domain services is carrying out some behavior involving entities or value objects. This can be demonstrated using two Competitor entities and an OnlineDeathmatch entity, all taken from the domain model of an online gaming system. They are shown in Listing 17-1 and Listing 17-2, respectively.

On completion of an OnlineDeathMatch, each player has his score updated based on how he performed in the game. One option for locating this logic is to place the score calculation and reward logic within the OnlineDeathmatch, as shown in Listing 17-3.

One big problem with CalculateNewPlayerScores() being part of the OnlineDeathMatch is that the rules are flexible; the business may want to award double points or hand out special prizes at certain times. What the business is saying in cases like this is that score and reward calculation are fundamentally important concepts within themselves. The same special promotions are often applied to different types of games: TeamBattle, CaptureTheFlag, GangCrusade, and so on.

This scenario is hinting at the need for domain services that encapsulate the single responsibility of a specific score or reward policy. Listing 17-4 shows the IGamingScorePolicy and IGamingRewardPolicy domain service interfaces that you can inject and apply into an OnlineDeathmatch or any other type of domain object that needs them.

Using the approach in Listing 17-4, you can switch in and out specific score and loyalty calculations according to the latest business promotions. Equally as importantly, you can now make these concepts explicit in the domain. For example, when a business is running its “free 12-month subscription for high scores” promotion, you can model this explicitly in the domain as a Free12MonthSubscriptionForHighScoresRewardPolicy domain service, as shown in Listing 17-5.

Listing 17-5 shows the Free12MonthSubscriptionForHighScoresRewardPolicy domain service that explicitly defines an important domain concept that exists within the UL. This domain service contains important business rules, lives inside the domain model, and hence is pure. However, some domain services are not implemented within the domain model; instead, their implementation lives in the service layer.

Representing Contracts

The other broad use case for domain services is as a contract—where the concept itself is important to the domain, but the implementation relies on infrastructure that cannot be used in the domain model. An example of this is ShippingRouteFinder, shown in Listing 17-6. You can see that it makes a web request to the routing API so that it can find the available routes for the given journey endpoints.

Importantly, the logic of making HTTP requests to a web server cannot live in the domain because it is an infrastructural concern; therefore, the implementation of the ShippingRouteFinder domain service in Listing 17-6 cannot live in the domain model. But the concept is part of the UL, so the interface must.

You can use domain services as contracts for a variety of scenarios, including:

• Entity identification
• Exchange rate lookup
• Tax lookup
• Real-time notifications

Manually Wiring Up

If an entity or other domain object depends on a domain service, you can pass the relevant service into the constructor if you are managing object construction yourself. Listing 17-10 exemplifies the desirable solution of using a factory method to solve this problem.

Listing 17-10 shows how you can pass a RestaurantNotifier domain service into the constructor of the RestaurantBooking entity that is manually constructed inside the CreateBooking() factory method. Factories are a common pattern that you see in many codebases. So far so good. But this solution becomes problematic in DDD when you don’t handle construction of the entity yourself—typically when an ORM loads an entity from persistence.

You can still work around an object’s life cycle that an ORM is managing, but the solution is not necessarily pretty. Listing 17-11 shows how your factory methods can add a second stage of object construction that sets the domain service as a property on the entity after an ORM has constructed it. In a similar fashion, you can have an Init() method that takes all the dependencies and sets them, like a pseudo-constructor. Either way, you’re open to the problem of forgetting that construction of the object occurs in two phases, which can lead to inconsistent states in production systems with lots of ensuing head scratching.

You may have thought of other problems associated with two-phase construction, such as remembering to apply the pattern consistently across the codebase and being disciplined to ensure that Init() is not called again after the object has been constructed.

If all this manual configuration is undesirable for you, you may prefer to offload some of it to an Inversion of Control (IoC) container by using dependency injection.

Using Dependency Injection

Another approach is to dependency-inject domain services into the entities that need to use them. Once a domain service has been added as a constructor parameter, the remaining task is to wire up the desired implementation using standard dependency injection. Using dependency injection saves you the hassle of manually constructing objects. It’s mainly a question of style whether you choose this or manually wiring up your dependencies, though, because the problem of dealing with ORMs may still be present.

With some ORMs, it’s possible to have them wire up dependencies that your IoC container manages. Unfortunately, though, with many it is not. However, if you’re still determined to use an IoC container and an ORM, the service locator pattern is one potential solution.

Using a Service Locator

Advance warning: the service locator pattern is fairly controversial; you’ll learn why shortly. However, you can see in Listing 17-12 how it solves the problem of allowing IoC containers to handle setting the dependencies of entities that are loaded by ORMs, without the need for manual intervention.

By taking the hard-coded dependency on the ServiceLocator class shown in Listing 17-12, you can load all of an entity’s dependencies from an IoC container during object construction after an ORM has initialized it. This removes the need for manual construction steps. But there’s a price; now the entity is tightly coupled to the ServiceLocator—an infrastructural concern that ideally you don’t want polluting the domain model.

The real problems with using a service locator arise from the tight coupling; you have to mock mocks in your tests, for example. Another problem is the obscuring of an object’s dependencies, because they’re no longer passed into the constructor.

Applying Double Dispatch

If you’re happy to forego passing domain services into entities at construction time, you have the option of instead passing them as method arguments using the double dispatch pattern. With double dispatch, a domain service is passed into a method on an entity, and the entity then passes itself into a method on the domain service, as shown in Listing 17-13.

As Listing 17-13 shows, domain services no longer need to be supplied into an entity’s constructor. Instead, they can be passed into methods on an entity by an application service. This approach hasn’t proven to be massively popular for a few reasons. Some feel that passing dependencies into methods requires callers of the method to supply the dependency—a responsibility that shouldn’t belong to them. Others argue that dependencies normally go via the constructor because they should not be part of a method’s signature; they’re an implementation detail that may be changed, whereas the method signature should not be so volatile.

So double dispatch is not to everyone’s liking, but neither are any of the other options presented so far. It’s definitely best to explore the idea yourself and assess how it may work on your projects. One approach that has become popular, though, is using the domain events pattern, with the promise of truly decoupling entities from domain services.

Decoupling with Domain Events

An interesting pattern that completely avoids the need for injecting domain services into entities is domain events. When important actions occur, an entity can raise a domain event that is handled by subscribers who are registered for that event. As you might have guessed, domain services can reside within a subscriber, and therefore, not an entity.

Listing 17-14 highlights the RestaurantBooking entity raising a BookingConfirmedByCustomer domain event. Listing 17-15 shows an event handler, also known as a subscriber, which handles this type of event by invoking the IRestaurantNotifier domain service. Finally, Listing 17-16 shows the small amount of work required to stitch these components together.

Listings 17-14 to 17-16 show a minimum possible example of the domain events pattern applied to the ongoing restaurant booking example. Chapter 18, “Domain Events,” is dedicated to the domain events pattern and provides more in-depth examples that explore the strengths and weaknesses of the pattern. One obvious drawback that you may have discerned from Listings 17-14 to 17-16 is that the logic is now distributed between the RestaurantBooking entity and the NotifyRestaurantOnCustomerBookingConfirmation event handler, whereas with other patterns this would be a single piece of sequential code.

Should Entities Even Know About Domain Services?

In the previous example, you saw how domain events preclude injecting domain services into entities, whereas each of the other patterns goes in the opposite direction and tries to find a way to make the dependency feasible. The latter is a fairly contentious approach within the DDD community; many practitioners argue that it’s just a bad idea. Ultimately, you need to use context, personal preferences, and your experience to decide which option you like the best.