Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
1  
Is there such thing as "mutable value object"? I always had the impression value objects are immutable. –  herby Dec 13 '12 at 8:53
    
@herby I guess you could have a mutable object representing a DDD value object in code, but you would have to consider that once you mutate the object, it's not referencing the same logical DDD value object anymore but a new one. This might be desirable but it's a recipe for confusion imo - making value objects immutable in code is a smart convention. –  MattDavey Dec 13 '12 at 9:44

3 Answers 3

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.

share|improve this answer
    
Domain identities, to my understanding, has nothing to do with persistence identity. According to Mr. Evan's book. –  Tony Dec 12 '12 at 23:43
    
You are right. I edit my answer. What I mean is that the object Address does matter in this specific domain, it's unique. IMO the Foreign Key and Primary Key is a sign that it's actually a unique object in the whole domain, so it has an identity. –  margabit Dec 13 '12 at 8:34
1  
"the address object... has it's own identity" -- which attribute of an address uniquely identifies it? No single attribute of an address is unique, but the combination of attributes serves as the identity. This is the very definition of a value object –  MattDavey Dec 13 '12 at 9:32
    
@MattDavey: it's a good conclusion, but I get confused when Tony says "we don't want to delete the row thou, because that address's PK is a FK in a MailingHistory table". This means to me that the Address object has also a meaning outside the Aggregate 'Insured'. Which points me that the 'Address' object should not be a ValueObject. What do you think? –  margabit Dec 13 '12 at 10:15
    
Could we say that Value Objects would invariably be wholly owned composition (UML) by the parent ? Additionally a Value Object would make no sense without its Parent and cannot be shared between Parents ? –  Sudarshan Feb 20 '13 at 6:53

I see 2 things:

  1. 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.

  2. 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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.