Using the Domain Model pattern - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 68

Services
The fifth and final kind of objects that are found in a domain model are services ,
which implement the workflow of the application. These classes are the driving
force of the application, with the methods that fulfill a use case. Generally, ser-
vices include behaviors that cannot be assigned to a single entity and consist of
methods that act on multiple objects. An example of a service in this domain
model is PlaceOrderService , which defines methods corresponding to the steps
of the Place Order use case.
A service consists of an interface and an implementation class. It is invoked by
the domain model's client, which is either the façade or the presentation tier. A
service method rarely implements a significant amount of business logic. Instead,
a typical service method retrieves objects using a repository and then delegates to
them. For example, PlaceOrderService calls RestaurantRepository and Pending-
OrderRepository and mostly delegates to PendingOrder .
The methods defined by a domain model service are very similar to those
defined by a session façade or a POJO façade. The methods usually correspond to
the steps of the use case. However, a service, unlike a façade, doesn't deal with such
things as performing transactions, gathering the data that must be returned to the
presentation tier, detaching objects, and all of the other things that the façade has
to deal with. Instead, it just focuses on pure business logic. Keeping the service sep-
arate from the façade is useful because you can work on the service and the rest of
the domain model without worrying about “plumbing” and other infrastructure
issues. In fact, as you will see in the next section, the service is a good place to start
when implementing a domain model.
3.2 Developing a domain model
Now that you have seen what a domain model is and how it fits in to the overall
architecture of an application, let's take a step back and see how to go about
developing one from scratch. The process of developing a domain model takes
the application's requirements, which are typically use cases or stories, and creates
an executable and tested domain model. There are many ways to develop a
domain model, and you could very well have your own preferred strategy. In this
section I'm going to describe a simple, informal approach that has worked well
for me in the past. It's an approach that you can use to develop a domain model
for your application.