Domain Driven Design or DDD for short is a huge but interesting topic. It has many complex subjects focused on business and technical perspectives. In the technology industry, people always talk about how both perspectives should work together in order to give the business benefits. However, that is not an easy task and it is when DDD appears in the scene. In this course, you are going to learn the most important concepts of DDD. You will see some concerns, techniques to model, how DDD can be implemented using hexagonal architecture and many other amazing concepts.

Domain Driven Design (DDD) Made Easy

As it was shown in the [previous lesson](https://www.educative.io/collection/page/4927079282376704/4708195672522752/5718229709750272), DDD has some tactical patterns to represent a model. There are three possible domain objects to implement business logic: Entities, Value Objects, and Aggregates. Consider creating an object that does not need identification such as an amount with value and currency. Value objects tackle just that.

Before going further with the definition of value object, it is worth looking at a common situation of the real world. It describes from the real world perspective what a value object is. **Eric Evans** mentions this situation in his book about Domain Driven Design: *When a child is drawing, he cares about the color of the marker he chooses, and he may care about the sharpness of the tip. But if there are two markers of the same color and shape, he probably won’t care which one he uses. If a marker is lost and replaced by another of the same color from a new pack, he can resume his work unconcerned about the switch.*

## What is a value object? 
A value object is a representation of something that is involved in a business process. Unlike entities, its attributes define value objects. It means value objects do not have an ID, and they are identifiable by their set of attributes. That's why these objects are immutable. Some common examples of value objects are Address, emailAddress, Amount. Everything depends on how the model was defined.


As it was shown in the [previous lesson](https://www.educative.io/collection/page/4927079282376704/4708195672522752/5718229709750272), DDD has some tactical patterns to represent a model. There are three possible domain objects to implement business logic: Entities, Value Objects, and Aggregates. Consider creating an object that does not need identification such as an amount with value and currency. Value objects tackle just that.

Before going further with the definition of value object, it is worth looking at a common situation of the real world. It describes from the real world perspective what a value object is. **Eric Evans** mentions this situation in his book about Domain Driven Design: *When a child is drawing, he cares about the color of the marker he chooses, and he may care about the sharpness of the tip. But if there are two markers of the same color and shape, he probably won’t care which one he uses. If a marker is lost and replaced by another of the same color from a new pack, he can resume his work unconcerned about the switch.*

# What is a value object? 
A value object is a representation of something that is involved in a business process. Unlike entities, its attributes define value objects. It means value objects do not have an ID, and they are identifiable by their set of attributes. That's why these objects are immutable. Some common examples of value objects are Address, emailAddress, Amount. Everything depends on how the model was defined.


Learn what value objects are and how they are implemented in Domain Driven Design.

Introduction

Mapping Domain to Model

Domain Activities

Domain Objects

Domain Abstractions

Hexagonal Architecture

Value Objects