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

■ TimeRange : Consists of a day of the week, as well as the start and end time.
■ Order : Represents an order that is created at the end of the Place Order use
case. Like PendingOrder it has a delivery address, line items, and a restau-
rant, and it can also have a coupon. In theory we could have used the Order
class to represent both the order being entered and the placed order, but
this would have made the application more complex. Using two separate
classes simplifies the design.
■ Coupon : Represents a discount that can be applied to an order. Coupons are
identified by a code and are valid only for a specified time period. The Coupon
class is another example of the Strategy pattern. Like the OverdraftPolicy
you saw in chapter 1, it is an interface and has several implementations—one
for each kind of coupon.
■ PendingOrderRespository : Defines methods for finding and creating
PendingOrder s.
■ OrderRepository : Defines methods for finding and creating orders.

RestaurantRepository : Defines methods for finding restaurants.

■

There are also some other classes such as the Address class, which represents an
address, and PaymentInformation , which stores payment information.
This is a pretty simple domain model, but it still has quite a few classes. A com-
plete domain model for an enterprise application would contain a great many
more. Finding your way around a large domain model can be a lot easier if you
know the roles the different classes play.

3.1.3 Roles in the domain model

Even though domain models from different problem domains are wildly differ-
ent, the classes can be categorized by their role in the domain model. Identifying
the role that a class plays can make it easier to name the class and help with the
designing the domain model. As you will see, a class's role implies certain kinds of
responsibilities and relationships with other classes in the domain model. Under-
standing these roles will help you develop your own domain model.
There are several different naming conventions for roles. My favorite scheme is
based on the one in Domain-Driven Design [Evans 2003] and has the following roles:

Entities —Objects with a distinct identity

■

Value objects —Objects with no distinct identity

■

Factories —Define methods for creating entities

■