Modeling Domain Objects
There are a great many different methodologies and approaches to domain object modeling. Some
practices advocate letting the underlying data store drive your object model, whereas some practices
say, "Let the business domain drive the object model." In practice, we have found that a happy medium
between these two approaches results in a DOM that is both easy to work with and well-performing.
For small applications with only five or six database tables, it is often easier just to create one domain
object that corresponds to each database table. Although these objects are not strictly domain objects--
in that their creation is not driven by the problem domain but rather the data structure--they are close
enough for the purposes of such a simple application. Indeed, in many small applications, the result of an
extensive domain modeling process is an object model that matches the database structure entirely.
For larger applications, much more attention has to be put into the real-world problem domain and
the underlying data store. When we are building a DOM for an application, we usually focus on three
main points:
How the problem domain is structured
·
How the domain objects will be used
·
How the underlying data store is constructed
·
What we are looking for is a DOM that is as close to the ideal model as possible without affecting the
performance of the data store too much and without having too great an impact on code that has to use
the domain objects.
Typically, a DOM is quite granular, and you might end up with more than one class for a single
logical concept. For instance, consider the concept of an order in a purchasing system. Typically an order
is modeled as a single Order object with one or more OrderLine objects that represent each line item of
the order. Trying to model an order using a single object leads to an object model that is unnecessarily
coarse and unwieldy and difficult to implement and maintain. You should always look for opportunities
to increase the granularity of your domain objects when it makes working with the DOM easier.
You will also find that your DOM contains objects that do not exist in your datastore. For instance, a
typical purchasing system has some notion of a shopping cart, perhaps represented by Cart and
CartItem objects. Unless you are required to persist content across user sessions, chances are these
domain objects do not have corresponding tables for data storage. Remember, you are not simply
building an object-oriented representation of your database; you are modeling the business domain.
This point cannot be stressed enough. We have seen plenty of projects that created a pseudo-DOM
derived directly from the datastore, and inevitably these projects suffered from the lack of abstraction
that can be gained from a well-defined DOM.
We have found that a solid DOM comes from taking the time to look at your problem domain,
identifying the objects in the domain, and then looking at how the natural granularity of these objects
fits into the requirements of your application. Although we take both the utilization of the domain
objects and the underlying data store into consideration, we don't like to let these have undue influence
on our DOM.
It is important to remember that the goal of building a DOM is to create a set of classes that help you
and other developers build the application at a level of abstraction that is closer to the application's
problem domain. In general, we consider all other concerns secondary when building a DOM. For
example, if you find that performance is suffering because of the design of your DOM, feel free to fine-
tune the model. However, make sure that the problem is caused by the design of the DOM (e.g., a single
domain object was found containing a large number of long text fields like CLOB or TEXT, which impact
the performance of data retrieval). You don't want to reduce the benefits of your DOM out of the
mistaken belief that it is performing badly.
Search WWH :
