CHAPTER 12 ■ ENTERPRISE PATTERNS
can create Space and Event classes. Booking an event in a space can then become as simple as a call to
Space::bookEvent(). A task like checking for a time clash becomes Event::intersects(), and so on.
Clearly, with an example as simple as Woo, a Transaction Script is more than adequate. But as
domain logic gets more complex, the alternative of a Domain Model becomes increasingly attractive.
Complex logic can be handled more easily, and you need less conditional code when you model the
application domain.
Implementation
Domain Models can be relatively simple to design. Most of the complexity associated with the subject
lies in the patterns that are designed to keep the model pure—that is, to separate it from the other tiers
in the application.
Separating the participants of a Domain Model from the presentation layer is largely a matter of
ensuring that they keep to themselves. Separating the participants from the data layer is much more
problematic. Although the ideal is to consider a Domain Model only in terms of the problems it
represents and resolves, the reality of the database is hard to escape.
It is common for Domain Model classes to map fairly directly to tables in a relational database, and
this certainly makes life easier. Figure 12–11, for example, shows a class diagram that sketches some of
the participants of the Woo system.
Figure 12–11. An extract from a Domain Model
The objects in Figure 12–11 mirror the tables that were set up for the Transaction Script example.
This direct association makes a system easier to manage, but it is not always possible, especially if you
are working with a database schema that precedes your application. Such an association can itself be the