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

logic being concentrated in a few, large classes, a domain model consists of many
relatively small classes that have both state and behavior. For example, as you will
see later in this chapter, the domain model for the Food to Go application con-
sists of classes such as Order , Restaurant , and MenuItem .
An important issue when using the Domain Model pattern is how to access the
database. Many of domain model classes are persistent and correspond to data in
the database. Unless the domain model is extremely simple, the application must
use an object/relational mapping ( ORM ) framework to persist the objects. In
chapters 4-6 you will learn how to persist a domain model with Hibernate and
JDO , which are two popular ORM frameworks, and chapter 10 will show you how
to persist the domain model with EJB 3 .
Let's now look at how a domain model fits into the overall application archi-
tecture and its relationship with the presentation tier and persistence framework;
after that we will look at the structure of the domain model.

3.1.1 Where the domain model fits into the overall architecture

In an application where the business logic is organized using the Domain Model
pattern, the domain model is the core of the business tier. Consider, for example,
the application shown in figure 3.1, which consists of a presentation tier, a busi-
ness tier, and a persistence framework. As this diagram shows, the domain model
is invoked by either the presentation tier or by a façade that encapsulates the busi-
ness tier.
The presentation tier handles HTTP requests from the user's browser by call-
ing the domain model either directly or indirectly via a façade, which as I
described in the previous chapter is either a POJO or an EJB . Each request results
in one or more domain model methods being called. These methods perform
various business logic operations, including retrieving and validating data, per-
forming calculations, and updating the database.
The persistent domain objects are unaware that they are persistent. They are
transparently mapped to the database by the persistence framework. Only a few of
the domain model classes (which are called repositories , as you will see later in this
chapter) explicitly call the persistence framework to create, find, and delete per-
sistent objects. As a result, we can develop almost the entire domain model with-
out having to worry about persistence. The domain model consists of POJO s, and
any calls to the persistence framework are hidden behind interfaces. In the next
chapter we will look at the topic of persistence in more detail, but for now let's
examine the structure of the domain model.