Entities vs. Value Objects

I haven’t done a post in quite awhile. I have been taking care of my newborn boy Aidan of just about 2 months and needless to say I greatly underestimated the amount of time and effort it takes in the first couple of months for a new parent. We love him all the same and are getting enough sleep to not keel over and die. That being said, I hope everyone can forgive my absence.

I recently purchased Domain Driven Design by Eric Evans (I know, it took me this long to buy it) and have been working through the book finding that a lot of the ideas I have been practicing from reading Applying DDD and Patterns by Jimmy Nilsson, but Eric’s book definitely lays down a much better foundation to work off and wrap your head around. In hindsight, at Joe Ocampo’s recommendation I would urge anyone else looking at a DDD book to start with Eric’s and then read Jimmy’s. Jimmy’s book refers back to ALOT of the work outlined in Eric’s book.

One of the topics I have spent the most time reading over was Entities and Value Objects. These are two very important and ideas in a rich Domain Model (not to forget Aggregates and Repositories of course) and have to be identified very explicitly in the model. I don’t mean to undermine any other topics in the book, but to just focus on these ideas for this post as I could write ALOT of posts of the knowledge I’ve absorbed thus far from Eric’s book.

I have been hanging out on the Yahoo DDD Group for some time now. If any of of you are looking for great information from very knowledgeable people, then subscribe to the rss feed and hold onto your seat! Almost all of the posts on this group are gems in their own right. This leads me to my main point.

I started on a new project recently and thought very hard about the Entities/Value Objects in the first refactoring of the Domain. It was about a “State” object. State as in Florida or California. I thought about it and said to myself, A State is very clearly a value object since it is immutable and I can pass it to around to other objects in the model. Then once I thought some more, I figured, well maybe it is an entity because each instance of a “State” is obviously unique because you can only have one Florida or one California. After thinking about it for awhile I posted a question on the Yahoo group and got an amazing explanation from Daniel Gackle and just had to share it with everyone at LosTechies. At the same time, I also went back and read Joe’s post from a little while ago and understood much more coming back to it this time around.

You can read the post for yourself but I will paraphrase here because I loved this example and gave me real good insight into the idea of Entities vs. Value Objects. 

Here is the example: Imagine a table in a classroom filled with a large number of unopened bottles of water. When the class starts, the teacher says, “Everyone please grab a bottle of water from the table”. Everyone goes to the table and grabs any bottle, not caring which one to grab since they are all unopened bottles of water, thus they are all the same thing. They have no individual identity.

Now, the same scenario except this time the teacher opens one of the bottles and drinks from it and places it back on the table. When he tells everyone to get a bottle this time the students will get a SPECIFIC bottle. This is because the opened bottle now has an identity and no one wants to drink the teachers spit. Thus, now the bottles can be considered Entities because they identities have to be kept track of so we don’t get the one with spit.

To add to this example let’s think that for some crazy reason, everyone does not care about the teachers spit in the water bottle. If no one cares about the teachers spit then the bottles are value objects again because the spit is outside of the scope of the domain model.

So, to summarize Daniel’s response to my question. Look at the objects in the actual context of the domain. In my instance, I don’t really care if the state of Florida is passed between multiple users and there is no attributes in the Florida object that sets it apart from other Florida object. Therefore, the State class can be considered a Value Object. Now, the moment I want to keep track of which states have electronic voting machines, then the State class could become an Entity because there is clearly a specific identity and attributes that go along with it.

I hope that wasn’t too confusing. I’m trying to present the idea in the way I understood it. Please do go read the whole thread though. There are other people that really add to the description and make the meaning much more thick then what I can present here. Good Luck!

About Sean Chambers

I am a Senior software developer from Palm Coast, Florida. An advocate of Domain Driven Design, Behavior Driven Development, creator of FluentMigrator and community activist. I am married to my beautiful wife Erin and am the proud father of two wonderful children. I currently reside at ACI, a local insurance industry/mortgage software company that excels in creating solutions using Agile methodologies.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Joe

    <3 -- Great link. That's quite possibly one of the best explanations for a technical problem Ive ever seen.

  • That’s a very good explanation because context is king. However what I struggle with in the entity vs. value objects debate is how do the two differ when I implement them in code (and in the database). What are you thoughts on this?

  • Differentiation beyond the domain context into the application context confuses a lot of people. Hence why the Repository concept was created to address this very concern.

    Domain identity should not be confused with system identity. System identity is often need when the repository has to persist the entities to a relational database. At that time properties or private fields have to be created in order to persist entities and value objects.

    But lets say your repository were serializing to an XML file. You wouldn’t have this issue.

    The key here is not to make it more complicated then it needs to be focus on the Domain first from a Domain Context use the Domain Identities as lookup values.

    Using the car analogy again. The car has global identity its VIN within my domain because me as the customer that is what matters most to me. Within the car however the factory saw fit to Give the engine block a LOCAL identity within the car. But to me as the consumer I can care less.

    Does this make sense?

  • I appreciate the difference between domain and system identity. But if I look at an entity and a value object in the domain how can I tell the difference between the two?

  • @Jason

    That is actually a good question.

    I would imagine at first glance you wouldn’t be able to tell without knowing the context of the objects.

    Perhaps Joe can shed some light on this.

  • I love this question because I get to use the phrase I know and love “..it depends”

    Sean you are right that you have to know the context of the object in order to truly understand if it is a value object.

    For instance:

    Lets say that you have a Person object that contains an Address object that maps to an address table. The Person object acts as the aggregate root and has global domain identity (their name) within the family context. The address identity has local identity within the Person aggregate and the client has know knowledge of the ID field that is used to persist it. Just the repository for the person aggregate.

    remember that value objects are immutable, so you don’t care what happens to them, where Entities are not and any change in them causes them to be in transient state.

    Using the example above. The address class on its own does not have any meaning to me without its container in this case the person object. On its own I should never care if the address object changes. In fact it should not have a repository class. How ever if the address belongs to a Person and the address changes then it places the person in a transient state. Make sense?

  • Joe,

    I follow I think.

    So what your’re saying is that when dealing with value objects with changes, it doesn’t change the value object but any/all related entities since the value objects are just a subset of information that is normally housed within an entity.

    If I am heading down the right path here, then can all value objects be treated in this manner?

    I have another question about implementation details of a value object. On my group posting, let’s say I have “States” value objects that relate to states in the US. When I want to retrieve a list of states to display to the user would this information be accessed through the aggregate root or via a custom query that would return only these lookup values. Little off topic but this also got me thinking.

  • I agree that context is important. But say you start to work on an existing application. It is not immediately obvious from browsing the code what is an entity and what is not. So is some valuable information not being lost because it is not documented in the code?

  • I would say just browsing at the code would give you a basic idea of how everything is composed. Depending how supple the design of the domain model would determine the ease of this. If any information is not being presented through the domain then one would need to speak to a domain expert to get a better idea of how context is composed.

    Takes on this anyone?