Database Modeling and Domain Object Modeling
Although database modeling and domain object modeling are quite similar, the results you get from
each are rarely the same, and indeed, you rarely want them to be. When modeling a database, you are
looking for the structure that allows you to store and retrieve data in the most efficient and consistent
manner. When you are building a DOM, performance is obviously important, but so is building an
application on top of an object-oriented model that is easy to work with and makes assembling your
business logic simple. In general, we have found that it is best to model the database in the way that is
best for the database and to model the DOM, initially at least, in a way that is best for the DOM. You can
make any changes later, if and when you identify performance bottlenecks.
Modeling Domain Object Relationships
The most common mistake we see in a DOM, especially when the DOM is driven by the design of the
database, is that domain objects are created to represent relationships among table entities. This comes
from the fact that a many-to-many relationship between two tables in a database must have a join table
to construct the relationship. Relationships in a DOM should be modeled in a much more OOP-style
way, with domain objects maintaining references to other domain objects or lists of domain objects.
A common mistake when populating domain object data from a database, such as what would be
done in the data access layer of an application, is to assume that all related domain objects (e.g., when
retrieving data from the ORDER table into the Order domain object, the list of Item objects within the
Order object should be retrieved from the ORDER_ITEM table together) must be loaded from the database
as well--this is not so. See the section "Domain Object Relationships" for a more detailed discussion of
this problem.
To Encapsulate Behavior or Not?
You are not forced to have your domain objects encapsulate any behavior at all; indeed, you can choose
to have your domain objects represent just the state of your problem domain. In most cases, we have
found that it is better to factor out much of the business logic into a set of service objects that work with
domain objects rather than encapsulate this logic inside the domain objects. Typically, we place all logic
that interacts with components outside of the DOM into the service objects. In this way, we are reducing
the coupling between the DOM and components involved in application logic. This allows the DOM to
be used in a wider variety of scenarios, and often, you will find that the DOM can be reused in other
applications that solve problems in the same domain.
Where we like to encapsulate behavior in the DOM is in situations where the logic is implemented
purely in interactions between domain objects. The JPetStore sample application included with Spring
provides a great example of this that can be mapped to our purchasing system example. In this scenario,
a user has a shopping cart, represented by a Cart object, and a list of CartItem objects. When the user is
ready to purchase the items in her cart and create an order, the application has to create an Order object
along with a list of OrderLine objects that corresponds to the data modeled by the Cart and CartItem
objects. This is a perfect example of when behavior should be encapsulated inside the DOM. The
conversion from Cart to Order is coded purely in terms of domain objects with no dependencies on
other components in your application. In JPetStore, the Order class has an initOrder() method that
accepts two arguments, Account and Cart. All the logic required to create an Order based on the Cart
object for the user represented by the Account object is represented in this method.
As with most things related to modeling, there are no hard-and-fast rules about when to put logic
inside a domain object and when to factor it out into a service object. You should avoid placing logic
inside your domain objects when it causes your domain objects to depend on other application
components outside of the DOM. In this way, you are ensuring that your DOM is as reusable as possible.
Search WWH :
