title: Value objects in DDD - Why immutable?
body: <p>I don't get why value objects in DDD should be immutable, nor do I see how this is easily done.  (I'm focusing on C# and Entity Framework, if that matters.)</p>
  
  <p>For example, let's consider the classic Address value object.  If you needed to change "123 Main St" to "123 Main <strong><em>Street</em></strong>", why should I need to construct a whole new object instead of saying myCustomer.Address.AddressLine1 = "123 Main Street"?   (Even if Entity Framework supported structs, this would still be a problem, wouldn't it?)</p>
  
  <p>I understand (I think) the idea that value objects don't have an identity and are part of a domain object, but can someone explain why immutability is a Good Thing?</p>
  
  <hr>
  
  <p><strong>EDIT</strong>:  My final question here really should be "Can someone explain why immutability is a Good Thing <strong><em>as applied to Value Objects</em></strong>?"  Sorry for the confusion!</p>
  
  <hr>
  
  <p><strong>EDIT</strong>:  To clairfy, I am not asking about CLR value types (vs reference types).  I'm asking about the higher level DDD concept of Value Objects.</p>
  
  <p>For example, here is a hack-ish way to implement immutable value types for Entity Framework:  <a href="http://rogeralsing.com/2009/05/21/entity-framework-4-immutable-value-objects">http://rogeralsing.com/2009/05/21/entity-framework-4-immutable-value-objects</a>.  Basically, he just makes all setters private.  Why go through the trouble of doing this?</p>