Hello there. In the previous video, we talked about the Entity. In this video, we will talk about Value Objects. If you're ready, let's get started. Value objects represent the elements or concepts of your domain that are known only by their characteristics. They are used as descriptors for elements in your model and do not require a unique identity. Because value objects have no conceptual identity within the model, they are defined by their attributes. Their attributes determine their identity. Value objects don't need identity because they are always associated with another object and are therefore understood within a particular context. For instance, you may have an order entity that uses value objects to represent the order shipping address, items, courier information, and so on. 

Not one of these characteristics needs identity itself because it only has meaning within the context of being attached to an order. An order address that is not attached to an order has no meaning. Value objects are comparable based on their attributes, and entities are responsible for any equality checks. Because they are defined by their attributes, value objects are treated as immutable. That is, once constructed, they can never alter their state. A good example of a value object is money. It doesn't matter that you can't distinguish between the same £51 coins or $1 bills in your pocket. You don't care about the currency's identity, only about its value and what it represents. 

If somebody swapped a $5 bill for one you have in your wallet, it would not change the fact that you still have $5. Of course, in real life, money can have a unique identifier in the form of a serial number, but the domain model does not reflect real life. Instead, it is an abstraction of it built to fulfill the needs of use cases within the problem domain. The image in this slide shows the main concepts of a value object. Now, let's try to understand value objects through a small example. Imagine we have three classes named PersonID, PersonName, and Address. These classes are our value objects. Notice that none of them have any identification. Let's also have an entity class named Persons. Notice that the entity has an ID. Because value objects have no ID, we may have difficulty comparing the values they contain. Therefore, it's possible to make a simple comparison using the equals() method as follows.

So, what are the benefits of value objects? We can make our codes more expressive by using value objects. Besides, our codes are now more secure. Because a value object is an object that has no identity value, two value objects with the same values can be regarded as the same in terms of value and therefore are interchangeable. This is why value objects are always immutable. The fact that value objects are immutable will protect the operation processes against both thread safe and side effects. They give us flexibility in terms of internal representation. For example, we can easily change the PersonID class like that. Thus, we have the possibility to make a simple change without changing most of the PersonID client. 

To summarize, a domain model contains entities which are akin to characters in a movie, and just like characters in a movie, it's often their attributes that make entities interesting or useful. Modeling these important descriptive attributes is the role of a Domain Driven Design, DDD construct known as the value object. Value objects have no identity. They are purely for describing domain-relevant attributes of entities, usually in the form of some quantity. Having no identity to deal with  often makes working with value objects relatively pain-free and enjoyable. In particular, being immutable and combinable are two characteristics that support their ease of use. So, I think that's enough information about value objects. Let's take a short break here. And in the next video, we will talk about domain services. See you in the next video.