When modelling Aggregates move as much as possible of the behaviour away from the Entities within the aggregate into Value Objects, As more behaviour is needed this is added as new value objects, Paul Rayner recommends in a series of blog posts covering aggregates, entities and value objects, all concepts from Domain-Driven Design (DDD).
One common example describing aggregates is using a Purchase order with Line items connected to the order. Two cohesive objects like this is a good example of an aggregate and since in practice a business always works in the context of the order, never with line items individually, the purchase order becomes the root of the aggregate. The aggregate supports concepts at the business level and the boundary of the aggregate is what enforces invariants, e.g. business rules like maximum order amount. Persisting and retrieving always work through the aggregate root and always as a whole aggregate.
Value objects are for Rayner a key building block pattern, some reasons being:
- Adds expressive names to key concepts in a model.
- Increases the conceptual cohesiveness of objects.
- Enables moving from using primitives for simple domain concepts like name of a customer.
- Allows entities to focus on identity by delegating behavioral logic to value objects.
Rayner emphasizes that although Data Transfer Objects (DTOs) superficially looks like value objects they are just a technical solution predominantly used to transfer data, e.g. between layers. Value objects on the other hand represent concepts in the business domain.
Rayner recommends that value objects should be immutable and quotes Joshua Bloch:
Classes should be immutable unless there’s a very good reason to make them mutable….If a class cannot be made immutable, limit its mutability as much as possible.
Other reasons Rayner sees for making value objects immutable are:
- When used as keys or identifiers since these must not change.
- They are inherently thread-safe, simplifying working with concurrency.
Techniques for making objects immutable varies with programming languages and Chris Oldwood, a freelance developer, has described some examples of doing this.
When persisting value objects to a relational database (RDBMS) Rayner describes a few options:
- Inline value objects fields in the entity table, a simple design that also supports refactoring of value objects from an entity.
- Using a table for each type of value object, a design that allows for a list of value objects.
- Serializing the value object and store in a field in the entity table is a method that Rayner recommends for lists. Some databases support plain text formats like JSON but querying and indexing may have limited support. There may also be issues if the result of a serialization is huge.
Using a document database or a combination where one part of an object is stored in a RDBMS and the rest in NoSQL storage, cross-store persistence, are other options. Many document databases of today supports querying the documents without a need to store searchable properties separately.