Why Value Objects?
Value objects are a key building block pattern in domain-driven design (DDD). Here are some of the reasons why. They…
-
Give rich, expressive names to key concepts in our model
-
Increase the conceptual cohesiveness of objects, readability of our code and the overall suppleness of our design
-
Making value objects immutable reduces incidence of bugs, improves thread safety and encourages a functional composition style
-
Encapsulation (information hiding) reduces cognitive burden and increases communication
-
Reduces primitive obsession
-
Removes burden of maintaining state from entities, focusing them on identity and lifecycle. Entities delegate the bulk of their behavioral work to value objects.
Value Object’s are NOT Data Transfer Objects
Data Transfer Objects’s (DTOs) have become the dominant method for moving data between layers, such as propagating a database schema up through the layers. Data Transfer Objects and Value Objects are therefore two completely separate things.
They look the same superficially, but the entire purpose of a DTO is simply to move data from here to there, with no logic/behavior, just state (i.e. DTO is a technical solution to a technical problem). However, a Value Object represents a concept, rather than a mechanical contrivance to shuttle stuff around.
About the Author
Paul is a software design and development coach and mentor. He is available for consulting and training through his company, Virtual Genius LLC. He is the author of The EventStorming Handbook and major contributor to Behavior-Driven Development with Cucumber. He is also the founder and chair for the Explore DDD conference.