R – Domain Driven Design newbie, please explain ‘value objects’ and ‘services’ briefly

Reduced to the essential distinction, identity matters for entities, but does not matter for value objects. For example, someone's Name is a value object. A Customer entity might be composed of a customer Name (value object), List<Order> OrderHistory (List of entities), and perhaps a default Address (typically a value object). The Customer Entity would have an ID, and each order would have an ID, but a Name should not; generally, within the object model anyway, the identity of an Address probably does not matter.

Value objects can typically be represented as immutable objects; changing one property of a value object essentially destroys the old object and creates a new one, because you're not as concerned with identity as with content. Properly, the Equals instance method on Name would return "true" as long as the object's properties are identical to the properties of another instance.

However, changing some attribute of an entity like Customer doesn't destroy the customer; a Customer entity is typically mutable. The identity remains the same (at least once the object has been persisted).

You probably create value objects without realizing it; anytime you are representing some aspect of an Entity by creating a fine-grained class, you've got a value object. For example, a class IPAddress, which has some constraints on valid values but is composed of simpler datatypes, would be a value object. An EmailAddress could be a string, or it could be a value object with its own set of behaviors.

It's quite possible that even items that have an identity in your database don't have an identity in your object model. But the simplest case is a composite of some attributes that make sense together. You probably don't want to have Customer.FirstName, Customer.LastName, Customer.MiddleInitial and Customer.Title when you can compose those together as Customer.Name; they'll probably be multiple fields in your database by the time you think about persistence, but your object model doesn't care.

I think you have the concepts of the distinction between entities and value types correct as they are understood within domain driven design (though I am far from an expert in this matter - perhaps better to say you match my understanding of these concepts). However I would advise against using this as a deciding metric when choosing whether to model those objects as reference or value in C#.

The key difference between a value and reference type is that the value types are copied when they are passed to a method. This means that they are more likely to sit on the stack rather than the heap and can be more costly to pass around; as such the size becomes a factor for consideration. The recommendation is that a struct should be below 16 bytes in size (at the bottom of remarks here) and a comprehensive address structure (House Number, House Name, Street Region, City, Country etc...) will easily break this.

That being said though, the semantics of entity:value :: class:struct are very similar and I can see a lot of benefits from modelling the data that way (two people who live at the same address don't share that address since changing one person's address shouldn't change the other's. So having the address as a struct would enforce this kind of separation. Whereas all instances of a person in the application should point to the same person). But there are performance and memory considerations. Perhaps immutable classes would be a good fit for these value types?

To sum up: The distinction between entity and value in DDD is based around what the object is. In code is should be based on what you intend to do with it.