The Object Model and Domain Model patterns are often considered to refer to the
same thing. They may initially look exactly the same, because both carry data
extracted from storage. But after digging a bit, you’ll find that they have differences:
the object model contains only the data, whereas the domain model contains data
and exposes behavior.
The Order class that we’ve been looking at is a perfect expression of an object
model. It has properties that hold data and nothing more. You could add a computed
property that reports the full address by combining the values of other properties, but
this would be a helper method. It wouldn’t add any behavior to the class.
If you want to move on from an object model to a domain model, you have to add
behavior to the class. To better understand the concept of behavior, suppose you
need to know if an order exceeds the allowed total amount. With an object model,
you have to build a method on another class. In this method, you call the database
to retrieve the maximum amount allowed, and then compare it with the amount of the
order. If you opt for a domain model, on the other hand, you can add an IsCorrect
method to the Order class and perform the check there. This way you’re adding
behavior and expressiveness to the Order class.
Creating and maintaining a domain model isn’t at all easy. It forces the software
architect to make choices about the design of the application. In particular, classes
must be responsible for their own validation and must always be in a valid state. (For
instance, an order must always have a related customer.) These checks may contribute
to code bloating in the classes; so, to avoid confusion, you may have to create
other classes that are responsible for validation, and keep those classes in the
domain model.
The details of the Object Model and Domain Model patterns are beyond the scope of
this book and won’t be covered, but plenty of books focus on this subject and all its
implications. We recommend Domain Driven Design by Eric Evans (Addison-Wesley
Professional, 2004). We’ll discuss the Domain Model pattern and Entity Framework
in chapter 14.