Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
DDD: Entities and Value Objects

Finally, after 5 posts in the series, we get to the beginning point, the basis of all things… Entities and Value Objects. OK, maybe a small exaggeration, but Entities and Value Objects (VO) form the core building blocks of Domain Driven applications.

Why has it taken this long to get to something so fundamental? Well, mostly I got distracted by shiny things along the way – topics came up and I felt the need to “get them down on paper” before I forgot where I was. I am at that age where, if I don’t do something when I think of it, I rarely get around to it. Oh yeah, Entities and Value Objects – almost forgot!

Back in the good old days we used to have things called business objects, these were classes that held some data, had some methods, and we threw into a database.

DDD has refined this concept a little, by splitting the idea of these business objects into two distinct types, Entities and Value Objects 

Entities

“this is my Entity, there are many like it, but this one is mine”

The key defining characteristic of an Entity is that it has an Identity – it is unique within the system, and no other Entity, no matter how similar is the same Entity unless it has the same Identity.

Identity can be represented in many ways on an Entity – it could be a numeric identifier (the classic CustomerID), it could be a Guid (the classic … oh never mind), or it could be a natural key (like the CustomerNumber your Customer was given by your CRM system when they first bought from you).

Examples of common Entities are: Customer, Product, Container, Vehicle

Whichever way you choose to represent it, an Entity is defined by having an Identity.

Value Objects

The key defining characteristic of a Value Objects is that it has no Identity. Ok, perhaps a little simplistic, but the intention of a Value Object is to represent something by it’s attributes only. Two VOs may have identical attributes, in which case they are identical. They don’t however have any value other than by virtue of their attributes.

Another aspect common to VOs is that they should probably be immutable, once created they cannot be changed or altered. You can create a new one, and as they have no identity, that is just the same as changing another one.

Examples of common Value Objects: Money, Address, ProductCode

Hey, I’ve Heard of These, We Have Them in .Net!

Don’t confuse Entities and Value Objects with Reference Types and Value Types, they sound similar but bear only a passable resemblance. Both Entities and Value Objects would be usually be implemented in .Net as Reference Types (Class not Struct).

So Entities and Value Objects Just Store Data?

Definitely not! The point of DDD is to create a rich Domain – if you only stored data in your Entities and Value Objects, you would have an anaemic domain model – one of the primary anti-patterns to DDD.

Entities should have methods on them that logically belong there – so a Customer might have a .UpgradeToPreferredStatus and a VO representing Money may have a methods to .Add, .Subtract, and so on. These methods would obviously come from the Ubiquitous Language (“we can Upgrade a Customer to Preferred Status”, “we can Add two amounts of Money together”)

In fact, in DDD there is less concern about what or how the your Entities and VOs store data, and more concern about how they represent that data and how they manipulate that data.

Some would go so far as to remove Setters and Getters from them entirely – though my personal preference is to remove Setters only, and make Getters representative of the outside “shape” of the Entity.

For VOs create only constructors, after all they are meant to be immutable.

For Entities use only constructors or strong methods to make any changes. Directly changing properties can have nasty side effects, and leave Entities in a temporarily invalid state.

And We Put These Things Into Repositories Right?

Not quite, at least not all of them directly, we will cover that in the next part of the series, the concept of Aggregate Roots.

In Conclusion

The “”things” in your business will usually be represented by Entities and Value Objects in DDD. They form the shape of your Domain, and would generally be the things you draw up on that class diagram on the wall.

Previously:

1) Domain Driven Design: A Step by Step Guide
2) DDD: The Ubiquitous Language
3) DDD: Bounded Contexts
4) DDD: There Is No Database
5) DDD: Command Query Separation as an Architectural Concept

Reference:

InfoQ Free eBook : Domain Driven Design Quickly
Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)

Entities
Value Objects

del.icio.us Tags: DDD,Domain Driven Design,Practices and Principles


Posted 02-13-2009 3:10 PM by Jak Charlton

[Advertisement]

Comments

Kevin Berridge wrote re: DDD: Entities and Value Objects
on 02-13-2009 1:15 PM

I've been enjoying your series.  I wanted to put in a request for a future topic.  How do these Domain objects interact with the UI.  Suppose your user hits a button to upgrade a customer to preferred status.  How does the button get to the domain object and call the right method?  And more interestingly, how does the domain object update the UI, so the customer now looks like its in the preferred status?

Thanks!

Casey wrote re: DDD: Entities and Value Objects
on 02-13-2009 1:51 PM

Kevin

Thx for the comment ... I intend to put a mini sample with a few diagrams covering the overall cycle ... I'll make sure I ccover that stuff for you

DotNetShoutout wrote DDD: Entities and Value Objects - Casey Charlton - Insane World
on 02-13-2009 2:55 PM

Thank you for submitting this cool story - Trackback from DotNetShoutout

DaRage wrote re: DDD: Entities and Value Objects
on 02-14-2009 6:41 AM

we know  how to implement entities now how do you implement value objects? easily?

Casey Charlton - Insane World wrote DDD: Where is the Code? Another Brief Interlude
on 02-14-2009 12:28 PM

Right about now I can hear murmurs, "I haven't seen any code yet" That is because I view

Community Blogs wrote DDD: Where is the Code? Another Brief Interlude
on 02-14-2009 12:58 PM

Right about now I can hear murmurs, "I haven't seen any code yet" That is because I view

Arjan`s World » LINKBLOG for February 14, 2009 wrote Arjan`s World » LINKBLOG for February 14, 2009
on 02-14-2009 5:01 PM

Pingback from  Arjan`s World    » LINKBLOG for February 14, 2009

Daniel Teng wrote Weekly links #1
on 02-15-2009 5:01 AM

关于敏捷

FixingtheAgileEngineeringProblemblog.gdinwiddie.com/.../fixing-the-agile-en...

Reflective Perspective - Chris Alcock » The Morning Brew #287 wrote Reflective Perspective - Chris Alcock » The Morning Brew #287
on 02-16-2009 3:37 AM

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #287

progg.ru wrote DDD: Объекты-Сущности и Объекты-Значения
on 02-16-2009 6:21 AM

Thank you for submitting this cool story - Trackback from progg.ru

Casey Charlton - Insane World wrote DDD: Aggregates and Aggregate Roots
on 02-16-2009 9:51 AM

Download the eBook of the Series so far … We are family I got all my sisters with me Sister Sledge Some

Community Blogs wrote DDD: Aggregates and Aggregate Roots
on 02-16-2009 10:30 AM

Download the eBook of the Series so far … We are family I got all my sisters with me Sister Sledge Some

on 02-16-2009 12:55 PM

DDD/ALT.NET Casey has written a bunch more in his DDD series since my last update 4) DDD: There Is No Database 5) DDD: Command Query Separation as an Architectural Concept 6) DDD: Entities and Value Objects 7) DDD: Where is the Code? 8) DDD: Download

Casey Charlton - Insane World wrote DDD: Services
on 02-17-2009 4:38 PM

There can be no word more common in development, and no word used for such a multitude of different things

Community Blogs wrote DDD: Services
on 02-17-2009 4:44 PM

There can be no word more common in development, and no word used for such a multitude of different things

Casey Charlton - Insane World wrote DDD: What Kind of Applications Is It Suited To?
on 02-18-2009 2:20 PM

In many conversations, and in many comments here, you hear phrases like “well that’s not really suited

Community Blogs wrote DDD: What Kind of Applications Is It Suited To?
on 02-18-2009 2:39 PM

In many conversations, and in many comments here, you hear phrases like “well that’s not really suited

Casey Charlton - Insane World wrote DDD: The Repository Pattern
on 02-20-2009 3:30 AM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

Community Blogs wrote DDD: The Repository Pattern
on 02-20-2009 4:12 AM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

Casey Charlton - Insane World wrote DDD: Living In The Enterprise
on 02-21-2009 4:25 AM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Community Blogs wrote DDD: Living In The Enterprise
on 02-21-2009 4:48 AM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Seb wrote re: DDD: Entities and Value Objects
on 02-21-2009 7:25 AM

May I ask, why shouldn't a Value Object be modelled as a value type in .NET? They are very close to being the same concept. I'd say that a value object should most often be modelled as a value type (struct) in .NET but perhaps not always. Although, it is important to point out that they are part of different concepts (domain modelling vs programming languages). Perhaps you could reason abit around this?

Maybe it just comes down to how I like to model entities. A reference type (class) has an identity in memory. It usually also has an identify in a persistence database. Those identities doesn't have to be the same as the ID-property.  Infact, an entity doesn't necessarily need to expose an explicit identity. It just needs a way to be discovered again. The real identity of an entity is the instance itself.

And if you use that style of entities and value objects they become very close to the meaning of class and structs.

Jak Charlton wrote re: DDD: Entities and Value Objects
on 02-21-2009 9:23 AM

@seb

2 reasons ...

1) Structs are intended for "really small things" ... ints, doubles, DateTime, etc ... often Value Objects can be large ... Address, ProductCode ...

2) I dislike mixing struct and class ... you have to be aware of the fact they look alike but behave differently. Some may be more used to this than others, but on the whole... I avoid structs unless absolutely necessary

Insane World wrote DDD: Living In The Enterprise
on 02-21-2009 10:42 AM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Insane World wrote DDD: The Repository Pattern
on 02-21-2009 10:42 AM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

DDD Step By Step wrote DDD: Aggregates and Aggregate Roots
on 02-22-2009 3:35 PM

Download the eBook of the Series so far … We are family I got all my sisters with me Sister Sledge Some

DDD Step By Step wrote DDD: Services
on 02-22-2009 3:35 PM

There can be no word more common in development, and no word used for such a multitude of different things

DDD Step By Step wrote DDD: What Kind of Applications Is It Suited To?
on 02-22-2009 3:36 PM

In many conversations, and in many comments here, you hear phrases like “well that’s not really suited

DDD Step By Step wrote DDD: The Repository Pattern
on 02-22-2009 3:36 PM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

DDD Step By Step wrote DDD: Living In The Enterprise
on 02-22-2009 3:37 PM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Insane World wrote DDD: Living In The Enterprise
on 02-26-2009 4:08 PM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Insane World wrote DDD: The Repository Pattern
on 02-26-2009 4:08 PM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

Eman Enon wrote re: DDD: Entities and Value Objects
on 05-14-2009 11:45 AM

Great post. I wonder if you could shed some light on how you handle  all those lookup (type, category) tables having code/description and something start and end date. On app that I work right now it seems that for each entity there is some type/code table attached to it. I see them as entities as I am concerned with a code not all attributes, but chief architect here insist on calling them values.

BeyondNet wrote re: DDD: Entities and Value Objects
on 10-07-2009 1:17 AM

Good article, what is your opinion of CSLA. NET and its relationship with DDD?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)