Why Value Objects Matter in DDD: Benefits, Traits, and DB Simplification

Value objects are core domain objects in DDD and should be preferred over entities whenever possible because they are easier to create, test, use, optimize, and maintain.

1. Why Use Value Objects?

Many teams over‑model with entities, mapping every domain attribute to a database table and adding setters/getters, which leads to a complex object web heavily influenced by relational‑DB thinking. Shifting to value‑object‑centric modeling reduces unnecessary complexity and saves development time.

2. Characteristics of Value Objects

Measure or describe something in the domain.

Can be treated as immutable.

Combine related attributes into a conceptual whole.

When the measurement changes, replace the whole object.

Support equality comparison with other value objects.

Do not cause side effects on collaborating objects.

When you only care about an object's properties, it can be a value object. It should have no identity and avoid the complexity of entities.

3. Case Study: Address as a Value Object

In a personnel entity, attributes such as province, city, county, and street are fragmented. By extracting them into an "address" value object, the address becomes a cohesive attribute set.

4. Different States of Value Objects

4.1 Business Shape

Value objects, like entities, belong to aggregates but contain only data and limited behavior, without business logic.

4.2 Code Shape

Single‑property value objects defined directly as entity attributes.

Attribute‑collection value objects designed as separate classes (no ID) and referenced by entities.

Examples include a Person entity with single‑property value objects (id, name) and a multi‑property value object such as Address.

4.3 Runtime Shape

Entity instances have rich behavior, while value‑object instances are simple, supporting only initialization and whole‑object replacement. For example, a person can have multiple addresses; each address value object is immutable and replaced as a whole when changed.

4.4 Database Shape

Traditional modeling creates separate tables for each entity. Value objects enable a denormalized approach where the value‑object’s attributes are stored in the same table as the owning entity, reducing table count and simplifying queries.

5. Best Practices for Simplifying DB with Value Objects

Instead of creating separate tables for address and person, embed address attributes directly in the person table, preserving business meaning while avoiding extra tables.

Model address as a value object in the domain layer.

Persist address fields within the person table.

6. Pros and Cons of Value Objects

Advantages: simplify DB design, improve performance, keep business concepts clear. Disadvantages: may hinder fast queries on embedded fields and, if overused, can blur the conceptual boundaries of entities.

7. Relationship with Entities

Both are fundamental objects in microservices. They can be interchangeable in some scenarios, but the choice depends on business meaning, mutability requirements, and design preferences. DDD advocates starting from domain modeling rather than data modeling to avoid DB‑driven complexity.

References

https://tech.meituan.com/2017/12/22/ddd-in-practice.html

《实现领域驱动设计》

实体和值对象：从领域模型的基础单元看系统设计