Here is a little problem
Have an entity, with a value object. Not a problem. I replace a value object for a new one, then nhibernate inserts the new value and orphan the old one, then deletes it. Ok, that’s a problem.
Insured is my entity in my domain.
He has a collection of Addresses (value objects). One of the addresses is the MailingAddress.
When we want to update the mailing address, let’s say zipcode was wrong, following Mr. Evans doctrine, we must replace the old object for a new one since it’s immutable (a value object right?).
But we don’t want to delete the row thou, because that address’s PK is a FK in a MailingHistory table. So, following Mr. Evans doctrine, we are pretty much screwed here. Unless i make my addressses Entities, so i don’t have to “replace” it, and simply update its zipcode member, like the old good days.
What would you suggest me in this case? The way i see it, ValueObjects are only useful when you want to encapsulate a group of database table’s columns (component in nhibernate). Everything that has a persistence id in the database, is better off to make it an Entity (not necessarily an aggregate root) so you can update its members without recreating the whole object graph, specially if that’s a deep-nested object.
Do you concur? Is it allowed by Mr. Evans to have a mutable value object? Or is a mutable value object a candidate for an Entity?
Thanks
2
Everything that has an identity should be an Entity, and everything that does not have an identity is a simple value, hence a value object.
To quote Martin Fowler (which in turn qoutes Eric Evans)
- Entity: Objects that have a distinct identity that runs through time and different representations. You also hear these called “reference objects”.
- Value Object: Objects that matter only has the combination of their attributes.
Reason to make your address a Value Object:
If your address is mutable, you will likely screw up your mailing history in the end. For example, if you’re shipping items to an customer, you can’t be sure to which address you actually shipped something in the past if the address your MailingHistory table is referring to has been changed.
The MailingHistory entry We shipped A764 to address 657 could mean We shipped article A764 to Boston yesterday and We shipped article A764 to New York tomorrow.
If the mailing address has to been changed, there’s no need to delete the old one. Keep it, and mark it as inactive, and the new one as active.
Of course you could treat your address as a Entity, but only when updating it would not change the actual place the address is referring to, hence only allowing the correction of typos.
If you’re sure you could ensure that, than using an Entity would be possible.
But the best solution IMHO is to not referrence an address Entity in your mailing history, but rather save the specific address directly in your mailing history table (basically copying the data of the address).
This way, you always know where you shipped your stuff (or whatever you are mailing), and since you would use a mutable Entity, your address table won’t be cluttered up.
I’ve worked with/on several ERP systems, and nearly all of them used this approach.
You will have some redundancy in your database, but it’s the most pragmatic way IMHO.
3
I see 2 things:
-
Is it ok for change of Zip code to affect a history record? I think it would be logical for the history record to point to the old, unchanged address, so you know you send it to wrong address.
-
The moment MailingHistory has FK on the address the address stopped being a value object and became entity. Value objects don’t have identity, that allow other entities reference this identity. You can have addresses in single table with other tables pointing to it, but only effect is space saving. From domain point of view, if two entities have reference same type of value object, then they don’t share any kind of information.
IMO the address object is an entity in your domain. It’s shared by multiple entities, has it’s own identity and is unique accross the system.
Evans says:
An object defined primarily by its identity is called an entity.
5