The other day a friend asked me what the difference between a VO 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 the Flex idiom which could serve as a point of reference for others moving forward.
In general, it is much easier to understand what a VO 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 represents 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 (VOs)
As the name implies, a Value Object, more commonly referred to as a VO, is an object which simply provides values. VOs are entirely immutable; that is, all properties of a VO are read-only and assignments to those properties are specified only during object construction; after which, the properties of the VO can not be modified and, by design, should not require changes.
VOs are typically used to provide an aggregation of conceptually related properties whose values describe the 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, VOs do not implement any specific behavior. Conceptually, think of a VO as being nothing more than an object which holds a value or series of related values which describe something about the object when created. A typical example of a VO could be a UserLogin object which simply holds the values of the specified username and password when created. It is important to make the distinction between a VO and a Domain Model as, a VO is not a Model, but rather, a VO is nothing more than an object which holds values and could be used to describe any context.
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 the domain, while VOs simply describe a contextual state.
