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
“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.
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.
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.
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
InfoQ Free eBook : Domain Driven Design Quickly
Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)
del.icio.us Tags: DDD,Domain Driven Design,Practices and Principles
02-13-2009 3:10 PM