VALUE OBJECTS | Domain Model | Domain Layer | Domain Driven Design

Value Objects | Domain Model | Domain Layer | Domain Driven Design

Value Objects

From Evans:

Many objects have no conceptual identity.  These objects describe characteristics of a thing.

When I don’t care about some object’s identity, I carefully consider making the concept a value object. 

When designing Value Objects, I want to keep them away from the trappings of Entity life cycles, so I make the Value Object immutable, and remove any concept of identity.  

Additionally, I’ll override Equals to compare attributes, so that attribute equality is represented in my model.

What are Side Effects Free Functions

A method of an object can be designed as a Side-Effect-Free Function[Evans]. A function is an operation of an object that produces output but without modifying its own state. Since no modification occurs when executing a specific operation, that operation is said to be side-effect free. The methods of an immutable Value Object must all be Side-Effect-Free Functions because they must not violate its immutability quality. 

Immutable means the Client Cannot change the State of the Objects after it is created.

No Property, Methods or Event can cause to change the Sate of the object. Due to this immutability, the VO functions are predictable, testable and produce the same results.

After Creating the VO, all its methods become predictable. They are Side Effects free. They do not change the State of the Object. They do not change the Instance Variables.

VO do not have set properties, they accept all Instance Variable initialization in the Constructor. After initialization we can only call it methods and get predicatbale results.

By making my Value Object immutable, many operations are greatly simplified as they aree Side-Effect Free Functions.  

VO are not a type with read-write properties. It has only Read Methods those are predicatable based on what Data they are initialized.

I make it immutable, put all of the attributes in the constructor, and enforce attribute equality.

Value Object: An object that contains attributes but has no conceptual identity. They should be treated as immutable.

Example: When people exchange dollar bills, they generally do not distinguish between each unique bill; they only are concerned about the face value of the dollar bill. In this context, dollar bills are value objects. However, the Federal Reserve may be concerned about each unique bill; in this context each bill would be an entity.

Value objects

• Value objects are used as descriptors for elements in your model.
• Examples of value objects include Money, Currency, Name, Height, and Color.
• Value objects in one domain might be entities in another and vice versa.
• Value objects have no identity.
• Value objects are immutable; their values cannot change.
• Value objects are cohesive; they can wrap multiple attributes to fully encapsulate a single concept.
• Value objects can be combined to create new values without altering the original.
• Value objects are self-validating; they should never be in an invalid state.

Value Object

If having unique features is not that important for your objects; if these objects are specified thanks to their unique attributes, you should view them as so-called value objects. To figure out if this or that notion/concept should be considered a value, you need to check if it has the following features:

1. It measures, evaluates and describes a domain object
2. It can be considered to be a persistent notion/concept
3. It models a conceptually non-breakable concept that bundles multiple attributes together
4. It can be replaced if the evaluation or description method is altered
5. It can be compared with other objects using value’s equality relation
6. It transfers side-effect free functions to the bundled/bounded objects.

You should encounter objects like these much more often than it seems. They are easy to develop, test and support. This is exactly why you need to use value objects instead of entities wherever possible.

Rarely, value objects are created specifically to be modified later. To restrict access to specific fields, setters are set to be private, while the object’s constructor — public. The constructor receives all the objects that act as value’s attributes. Basically, value object generation needs to be a protected, atomic operation.

When it comes to value objects, it is important to implement the equality verification operation correctly. To make two value objects equal, all the types and values of the attributes need to be equal as well.

Also, it is important that all the methods of value objects need to be side-effect free functions. As they shouldn’t violate the persistence property, they can return objects but can’t modify their state. Let’s have a look at the example below:

Hide   Copy Code

public class Money implements Serializable {
private BigDecimal amount;
private String currency;
public Money (BigDecimal anAmount, String aCurrency) {
    this.setAmount(anAmount);
    this.setCurrency(aCurrency);
}
…
}

The setters are hidden/private, while value object generation is set as a protected, atomic operation. In this example, {50 000 USD} is a value. Separately, these attributes either describe other things or doesn’t mean anything at all. But 50 000 and USD have to do with this specific relationship. That said, these attributes create a conceptually integer value that describes a specific sum of money. This type of conceptual unity plays a huge role because there are types of values and values on their own that exist as directed by ubiquitous language within bounded context.

So far, we have looked through entity and value object. Let’s move on.

Value Objects

Vital element in domain modeling oriented to DDD. Concept of the domain model that does not have an identifier , but rather the element itself is identified by the value of its attributes . Used to describe, measure or quantify domain concepts . Adding information and describing the entity to which it belongs. In similarity and comparing it with a relational database, it would be the related tables through Foreign Key.

The Value Objects are immutable, their instances are atomic, they are not modified, they are replaced generating new instances, thus avoiding the risk of modification of the same instance shared in different contexts and scenarios with high concurrence ( Side-effect free behavior ).

To ensure such immutability and atomicity, we will hide their attributes using allocation methods for each property. Each Value Object will contain a minimum primary constructor, receiving the minimum parameters necessary to perform the instance by means of said assignment methods.

Some strategies for managing new instances in Value Objects memory include cloning the object in a new instance, subsequently modifying the attribute that it requests.

To determine the equality of independent instances in memory of Value Objects , all the values ​​of the properties of both instances will be checked: if all the values ​​of all their attributes are coincident.

Recommended readings: 
Domain-Driven Design: Entities and Value Objects Webcast at @AtrapaloEng (Spanish) 
Aggregates, Entities and Value Objects in Domain-Driven Design

Many objects have no conceptual identity. These objects describe some characteristic of a thing.

Tracking the identity of ENTITIES is essential, but attaching identity to other objects can hurt system performance, add analytical work, and muddle the model by making all objects look the same.

Software design is a constant battle with complexity. We must make distinctions so that special handling is applied only where necessary.

However, if we think of this category of object as just the absence of identity, we haven’t added much to our toolbox or vocabulary. In fact, these objects have characteristics of their own, and their own significance to the model. These are the objects that describe things.

Therefore:

When you care only about the attributes of an element of the model, classify it as a VALUE OBJECT. Make it express the meaning of the attributes it conveys and give it related functionality. Treat the VALUE OBJECT as immutable. Don’t give it any identity and avoid the design complexities necessary to maintain ENTITIES.