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?


  • 2
    Is there such thing as "mutable value object"? I always had the impression value objects are immutable.
    – herby
    Dec 13, 2012 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, 2012 at 9:44

3 Answers 3


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.

  • This is probably the most headache-free solution. Only if you expect that future communication channels will require extra columns, and your database is too large to ALTER, using entities in separate tables may become necessary. That, in turn, calls for strategies like "always join the newest address/phone/e-mail" in your SELECT queries, which are challenging to keep maintainable and efficient. Keep it simple, if at all possible.
    – Timo
    Mar 8, 2018 at 10:12
  • @Timo "always join the newest address/phone/e-mail" is not hard if you denormalize your data a little bit by simply adding an active-flag. Of course you have to make sure to always use and active = true in your Joins, keep the flag up-to-date and add a contraint to your table so that e.g. only one e-mail for each customer can have this flag set to true.
    – sloth
    Mar 8, 2018 at 10:54
  • This introduces the problem of deactivating the previous one. If you've replaced your instance's "current" Address object in code, and you go to your data access code, then it won't know (1) whether or not there is a new one, nor (2) what the potential old one was. So every save operation will have to do something convoluted like "first go and deactive all related addresses in the database", and then save the current one with active=true. This is not what I would call simple, which is exactly why I like your solution.
    – Timo
    Mar 8, 2018 at 14:38

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.


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.

  • Domain identities, to my understanding, has nothing to do with persistence identity. According to Mr. Evan's book. Dec 12, 2012 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, 2012 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, 2012 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, 2012 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, 2013 at 6:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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