When to use Value Objects in database
Question when to use value objects in database is usually discussed during storing a new set of data. Usage of value objects should be considered while modeling abstractions that are constant / immutable and do not require unique identity. Examples can be: geospatial data, estate addresses or any categories that belong to an entity.
VO also encapsulates validation logic and business rules. Helps to avoid raw strings or magic numbers.
When to use it and its benefits
- Composite Primitives: Primitive types like strings/ints replaced with rich types (e.g., EmailAddress over string). Prevents invalid data like „user@fake”validated in constructor.
- Embedded in aggregates: Store as own types or json columns. Simplificiation. An Order entity can hold Money (Amount + Currency) in same table since identical values are interchangeable.
- Immutable business rules: Coordinates, colors (RGB), calendar holidays. Changes? Create new instance.
How to map a value object in db
| Scenario | Mapping | Benefit |
|---|---|---|
| Embed | Columns in parent table (Street, City in Address) | Fast reads, no joins |
| Complex nesting | JSONB/PostgreSQL or owned entities | Flexible schema, validation |
| Collections | Array/JSON for lists | Denormalized speed |
Value object in domain driven design
This is the perfect model to describe our domain. Example could be an aieport with different type of plains where the value object represents every diferent type of an aircraft. Single flat or embedded table, easy to index, fast to query, simply extendable. Works like a charm in functional programming.
How to link value object to another dependency
The ID belongs to User, we load the VO email using foreign key for user_id or just embedded it as a column. Email has and will have no own ID. We will have to replace the entire Email Value Object to change the user email.
Primary benefit is encapsulation of validation and business rules. It ensures data integrity without scattered checks, everything is tightly composed in single class.
Value object key principles
- Lack of unique identity: Unlike entities like 'Shop’, value objects lack a unique ID. The most important is the structure and proper data. Imagine them like a very big enum 🙂
- Immutability: They are like war…that never changes. Need a new order? Create a new object with the cart. Zero side effects and very predictable, easy to understand. Decoupled.
- Validation during construction: Everything validated during construction phase, great news cause we will know WE DO NOT PUT GARBAGE INSIDE OUT DATABASE.
Summary, tl;dr
Start small in your personal project. You could replace a plain „email” string with an EmailAddress Value Object including validation. Errors drop significantly, code is more readable and documentation clearer. Experiment and test it yourself.
Bibliography
Implementing value objects – .NET (Microsoft Learn) – official, free docs
Value Objects explained – enterprisecraftsmanship
