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 from Perth, Australia, but chooses to live, work and play with his amazing wife and two children in Denver, Colorado. He co-founded and co-leads DDD Denver. Look for him speaking at local user groups, and at regional and international conferences.

If you are looking for an expert hands-on team coach and design mentor in Domain-Driven Design (DDD), BDD with Cucumber, or lean/agile process Paul is available for consulting and training through his company, Virtual Genius LLC.