more of mutable, immutable, stack, and heap

Again: Value types are immutable (they cannot change) while reference types are mutable, and value types go on the stack and reference types go on the heap.

http://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap asserts:

1. THE STACK is the memory set aside as scratch space for a thread of execution. When a function is called, a block is reserved on the top of the stack for local variables and some bookkeeping data.
2. THE HEAP is memory set aside for dynamic allocation. Unlike the stack, there's no enforced pattern to the allocation and deallocation of blocks from the heap; you can allocate a block at any time and free it at any time.

 
 

http://msdn.microsoft.com/en-us/library/yz2be5wk.aspx goes into boxing and unboxing which has to do with converting a value type to an object or, in the case of unboxing, an object back to a value type. An example of boxing:

int i = 123;

object o = i;

 
 

...of unboxing:

o = 123;

i = (int)o;

 
 

This image shows how another piece of memory is allocated in the boxing process. Hence, there are some performance issues with boxing as a value type on the stack gets copied to the heap as it is boxed. (That said, you are very likely better off worrying about how to optimize database integration in the name of reducing lag instead of having angst over boxing and unboxing.)

 
 

Value objects are not always just simple types:

http://tom-jaeschke.blogspot.com/2011/12/entities-have-both-state-and-lifecycle.html has my notes from when I saw Paul Rayner speak on DDD. He suggested that Eric Evans suggests that objects which are not entities (and thus do not have a lifecycle) should be (if not DTOs) value types. Examples given of value domain objects that one might speak about in ubiquitous language were:

1. Warranty (no lifecycle, once it's set its dates and conditions are not going to change)
2. Terms & Conditions (same thing)