You are currently browsing the Eric Feminella blog archives for December, 2010

Domain Models and Value Objects

The other day a friend asked me what the difference between a Value Object and a Domain Model was, and when I would suggest using one over the other? Since I actually get asked this very same question quite often, I thought it would be useful to provide a brief definition in the context of a language agnostic idiom which could serve as a point of reference for others moving forward.

In general, it is much easier to understand what a Value Object is not by first understanding what a Domain Model is; therefore, I will begin by providing a general definition of a Domain Model.

Domain Models

A Domain Model is anything of significance which represents a specific business concept within a problem domain. Domain Models are simply classes which represent such concepts by defining all of the state, behavior, constraints and relationships to other Domain Models needed to do so. Essentially, a Domain Model “models” a domain concept, such as a Product, a User, or anything which could be defined within the problem domain outside the context of code. Domain Models promote reuse and eliminate redundancy by defining specific classes which encapsulate business logic, state and relationships. As the domain concepts change, so to do the implementations of the Domain Models.

Value Objects

As the name implies, a Value Object, more commonly referred to as a VO, is an object which simply provides values. Value Objects are entirely immutable; that is, all properties are read-only and assignments to those properties are specified only during object construction; after which, the properties can not be modified and, by design, should not require changes.

Value Objects are typically used to provide an aggregation of conceptually related properties whose values describe the initial state of the object when instantiated and do not require any real concept of identity or uniqueness. While there are some edge cases (such as validation), more commonly than not, Value Objects do not implement any specific behavior. Conceptually, think of a Value Objects as being nothing more than an object which holds a value or series of related values which describe something about the object when created. It is important to make the distinction between a Value Objects and a Domain Model as, a Value Objects is not a Model, but rather, it is nothing more than an object which holds values and could be used to describe any context. A good example of a Value Object could be a JSON object returned from the server. That is a Value Object. A Domain Model could then wrap the Value Object in order to provide state changes, validation and behaviors.

And that’s it

Hopefully the above descriptions of both Domain Models and Value Objects will clear up any confusion surrounding the two concepts; ideally, making it easier to understand when to use each.

The point to keep in mind is that Domain Models simply model a business concept, including it’s rules, constraints and behaviors, while Value Objects simply describe a contextual state.