Domain-Driven Design: Tackling Complexity in the Heart of Software

Partitioning Services into Layers
Application
Funds Transfer App Service
Digests input (such as an XML request).
Sends message to domain service for fulfillment.
Listens for confirmation.
Decides to send notification using infrastructure service.
Domain
Funds Transfer Domain Service
Interacts with necessary Account and Ledger objects, making appropriate
debits and credits.
Supplies confirmation of result (transfer allowed or not, and so on).
Infrastructure
Send Notification Service
Sends e-mails, letters, and other communications as directed by the
application.
Granularity
Although this pattern discussion has emphasized the expressiveness of modeling a concept as a

---

SERVICE
, the pattern is also valuable as a means of controlling granularity in the interfaces of the
domain layer, as well as decoupling clients from the 
ENTITIES
and 
VALUE OBJECTS
.
Medium-grained, stateless 
SERVICES
can be easier to reuse in large systems because they
encapsulate significant functionality behind a simple interface. Also, fine-grained objects can lead
to inefficient messaging in a distributed system.
As previously discussed, fine-grained domain objects can contribute to knowledge leaks from the
domain into the application layer, where the domain object's behavior is coordinated. The
complexity of a highly detailed interaction ends up being handled in the application layer, allowing
domain knowledge to creep into the application or user interface code, where it is lost from the
domain layer. The judicious introduction of domain services can help maintain the bright line
between layers.
This pattern favors interface simplicity over client control and versatility. It provides a medium
grain of functionality very useful in packaging components of large or distributed systems. And
sometimes a 
SERVICE
is the most natural way to express a domain concept.